Jenkins pipeline is pending at https://scala-ci.typesafe.com/job/scala-2.13.x-validate-main/12079/console because error happened. Maybe it should be closed manually.

@changvvb would you mind rebasing against the current head of 2.13.x? that should make the problem go away

@changvvb would you mind rebasing against the current head of 2.13.x? that should make the problem go away

@SethTisue It seems not work 😕.

I'll re-fix the commits so we can reduce the noise merging this PR would bring.

@lrytz over at scala/community-build#1164 this caused a regression; one Akka source file started failing to compile. I isolated it to just:

import S._
@annotation.strictfp object S

error: encountered unrecoverable cycle resolving import.
Note: this is often due in part to a class depending on a definition nested within its companion.
If applicable, you may wish to try moving some members into another object.

(the exact annotation isn't important, e.g. @nowarn does the same thing)

such an import is a bit unusual. the Akka folks wanted it because they were doing this:

import S._
class C(x: Inner)
@internalApi object S { trait Inner}

and note that you can't move the import inside the class definition because the location where they want to refer to Inner is in a constructor parameter.

interestingly, Dotty has the same bug or limitation, whichever you want to call it:

scala> import S._ ; object S                                                                       
// defined object S

scala> import S._ ; @annotation.strictfp object S                                                                       
1 |import S._ ; @annotation.strictfp object S
  |              ^
  |              Cyclic reference involving module class S$

not sure if this is a 2.13.3-blocker or not. in the Akka source the problem is easy to work around because you can either 1) import S.Inner instead of import S._, or 2) skip the import entirely and just write out x: S.Inner

@smarter would you like me to open a lampepfl/dotty ticket on this?

I would suggest reverting this change for 2.13.3. Lazy typechecking of annotations can be relied on in pretty subtle ways.

Perhaps our annotation typechecking should have an extra phase:

1. Lazy we know nothing about the annotation
2. Typecheck the annotation qualifier, but not the arguments. This would be enough to answer Symbol#hasAnnotation / AnnotationInfo.matches, and would be transparently forced when calling these methods.
3. Fully typechecked

If there are still cases that could run into a StackOverflowError in the uncheckedStable lookup, we could add cycle detection to turn this into a cyclic error report.

I like the suggestion of lazily type checking the parts of an AnnotationInfo and making the whole thing more transparent.

I also agree that reverting is the safer choice for 2.13.3.

Yes, Symbol#hasAnnotation can be more clever.