-
Notifications
You must be signed in to change notification settings - Fork 21
signature inference for overriding val should propagate annotations #10471
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
Comments
@lrytz found the spot where the annotation is dropped:
|
the regression was introduced by scala/scala#5141 to fix #2742 |
Simply dropping the calls to patchSymInfo breaks pos/t6780.scala. I've been trying to remember what the second comment was about:
I'll experiment some more tomorrow. /cc @retronym |
When removing the object O {
implicit def i: Int = 0
}
import O._
trait Foo {
implicit val v1: Any
}
trait Bar1 extends Foo {
implicit val v1 = {implicitly[Int]; ()}
}
|
I checked why we don't have the t6780 problem with methods (change the two So now I need to check why the original problem (annotations disappearing) doesn't happen for methods. In larger terms, this is related to #10459 (why do we even assign annotations in the type completer? Couldn't we do it using lazy annotations directly in the namer?) |
When requesting the field's info in the AccessorTypeCompleter, don't skip the ValTypeCompleter, which sets the annotations on the field symbol. Fixes scala/bug#10471
So the difference is that the Testing this in scala/scala#6040. So it's also order-dependent: when the field symbol is completed before the getter symbol, the annotation is there. This can be observed by removing the |
Build log: https://scala-ci.typesafe.com/job/scala-2.12.x-validate-test/5436/consoleFull
In |
scala/scala#6040 is not a working solution, the additional calls to |
That would probably be the safest fix for now. adriaanm/scala@33d444d |
If I understand correctly, this would pick annotations from the overridden symbol? That's not what should be done, we need the (filtered) annotations that are in the ValDef tree. |
When the AccessorTypeCompleter gets the type signature of the ValDef, ensure that the ValTypeCompleter runs (which sets the annotations on the field symbol) instead of just calling typeSig. Fixes scala/bug#10471
When the AccessorTypeCompleter gets the type signature of the ValDef, ensure that the ValTypeCompleter runs (which sets the annotations on the field symbol) instead of just calling typeSig. Fixes scala/bug#10471
When the AccessorTypeCompleter gets the type signature of the ValDef, ensure that the ValTypeCompleter runs (which sets the annotations on the field symbol) instead of just calling typeSig. Fixes scala/bug#10471
scala/scala@c665180 maybe? |
You're right. Thanks, your fix LGTM. |
When the AccessorTypeCompleter gets the type signature of the ValDef, ensure that the ValTypeCompleter runs (which sets the annotations on the field symbol) instead of just calling typeSig. Fixes scala/bug#10471
under
-Xprint:typer
, we see that the field forC2.foo
is not annotated with@blort
The text was updated successfully, but these errors were encountered: