I cannot reproduce the issue. The code compiles fine for me with Scala.js 1.0.1, with Scala 2.12.11 and 2.13.2.

I will try to re-create a minimum repro.

Updated the above example, which now contains js.UndefOr field with default value.

I also opened a repository for reproduction.

$> git clone https://github.com/exoego/scalajs-1-amiguous-ref.git
$> cd scalajs-1-amiguous-ref/
$> SCALAJS_VERSION=0.6.33 sbt clean compile 
$> sbt clean compile 

Then you will see error like below:

[info] Compiling 1 Scala source to /home/vagrant/scalajs-1-amiguous-ref/target/scala-2.12/classes [error] /home/vagrant/scalajs-1-amiguous-ref/src/main/scala/com/example/Foo.scala:12:9: reference to b is ambiguous; it is both a method parameter and a variable in scope.
[error]       b = this.b
[error]         ^
[error] one error found
[error] (Compile / compileIncremental) Compilation failed
[error] Total time: 1 s, completed 2020/05/14 15:23:23

OK now I can reproduce the issue with Scala 2.12.11. However it is clearly an error message reported by the Scala type checker, which we have no control over, and it is fixed with Scala 2.13.0+. So I'll close this as "upstream".

(The reason it changes between 0.6.x and 1.x may be that js.UndefOr[A] became an alias to A | Unit rather than being its own magical thing. The release notes of Scala.js 1.0.0 mention that this may cause small differences for type inference in some corner cases. This might be such a case.)

Not sure this is the right place to ask this: But what is our policy on closing bugs marked as "upstream"?

The reason I'm asking is that IMHO #3918 and #3953 are similar from a user's perspective. Differences I can see:

• not fixed in 2.13.x (user visible difference)
• we have a chance of fixing them (not a user visible difference)
• they are an issue with the compiler API (not a user visible difference).

Am I forgetting something?

I think it's mostly a question of

• If we don't have a chance of fixing them, close.
• Otherwise, if it already fixed upstream, close.
• Otherwise, if it is reported upstream and upstream acknowledges that it should be fixed upstream, close.
• Otherwise, keep.

Does that make sense?

Does that make sense?

Yes, but it's inconsistent with #3818 (comment) IIUC. I think the approach of closing stuff that is unactionable on our end is good.

#3818 was actionable on our end, although not before 2.13.2 was released. The very fact of upgrading our stdlib to 2.13.2 fixed the issue. If we had never upgraded our stdlib, then even users using 2.13.2 would not have benefited from the fix. Another way to look at it is that there is clearly one commit in our repo that fixes the issue. Before that commit, it was broken; after that commit, it was fixed.

Here this is different. There is no commit in this repo that turns it from "it doesn't work" to "it works". It's the fact of using a more recent upstream compiler that fixes it, independently of the version of Scala.js.

Yeah, OK that's a fair way of looking at it. But then we still need to remove the bullet:

Otherwise, if it is reported upstream and upstream acknowledges that it should be fixed upstream, close.

Because that never happens without triggering the situation that we at least have to upgrade Scalac.

But we don't really upgrade scalac. We publish our plugin for all versions of scalac. We even back-publish our compiler plugin for newer versions of scalac in past versions of Scala.js. Clearly in those cases the bug is entirely fixed upstream, without any commit from our repo entering into account (we're using a commit from the past in that case!).

Right... That's quite subtle, but fair enough :)