Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False reference ambiguity with redundant import and opaque type #14684

Open
pikinier20 opened this issue Mar 14, 2022 · 2 comments
Open

False reference ambiguity with redundant import and opaque type #14684

pikinier20 opened this issue Mar 14, 2022 · 2 comments

Comments

@pikinier20
Copy link
Contributor

pikinier20 commented Mar 14, 2022

Compiler version

Reproduced on newest nightly, 3.1.2-RC1, 3.1.2-RC2, 3.0.0

Minimized code

To reproduce this bug, we need three files:

package bar

package baz {
  import util.HTML._

  class TrashRenderer:
      raw("")

}
package bar

package foo {
  import util.HTML._
  import bar.util.HTML._

  object Bazzz:
    raw("asd").toString
}
package bar
package util {
  object HTML:
    opaque type AppliedTag = StringBuilder

    def raw(content: String): AppliedTag = new AppliedTag(content)
    def raw(content: StringBuilder): AppliedTag = content
}

I found out that there are some conditions that must be satisfied for this bug to occur:

  • There must be opaque type in object HTML
  • There must be nested package in the file where the raw method is used so that we can import it by absolute and relative path
  • There must by second usage of raw somewhere

Output

[error] -- [E049] Reference Error: /Users/fzybala/Documents/random/ambiguous-reference-bug/src/main/scala/dotty/tools/scaladoc/tasty/comments/markdown/bug.scala:8:4 
[error] 8 |    raw("asd").toString
[error]   |    ^^^
[error]   |    Reference to raw is ambiguous,
[error]   |    it is both imported by import bar.util.HTML._
[error]   |    and imported subsequently by import bar.util.HTML._

Expectation

Should compile

This problem caused CI to fail on one of my branches in Scaladoc: #14669. Of course double-import is not a good thing but usually compiler knows that it's the same thing.

@pikinier20 pikinier20 added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 14, 2022
@pikinier20
Copy link
Contributor Author

I tried to look into compiler where exactly this message is thrown and I got to TypeComparer. There's a method isSameRef that compares if two types are the same refs. When we don't satisfy one of conditions that I mentioned, the method is called with tp1 that shows: <overloaded bar.util.HTML.raw> and tp2 that shows: <overloaded bar.util.HTML.raw> and therefore it returns true. In the example that I've provided, the method gets other parameters: tp1 : <overloaded bar.util.HTML.raw> and tp2 :

(bar.util.HTML.raw : 
  (content: String): bar.util.HTML.AppliedTag
)

and therefore, the check in method:

tp1.alternatives forall (isSubRef(_, tp2))

returns false.

So, something changes the tp2 from overloaded method to one of its concrete alternatives.

@pikinier20 pikinier20 added area:typer area:opaque-types and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 15, 2022
@odersky
Copy link
Contributor

odersky commented Mar 15, 2022

I guess it's some strange completion order that makes the compiler not see one of the alternatives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants