Use of companionSymbol in custom namer leads to cyclic errors.

[retronym]

This code:

        // this will only show companions defined above ourselves
        // so when finishing `class C` in `{ class C; object C }`
        // we won't see `object C` in `companion` - we will see NoSymbol
        // that's the limitation of how namer works, but nevertheless it's not a problem for us
        // because if finishing `class C` doesn't set up the things, finishing `object C` will
        val sym = tree.symbol
        val companion = companionSymbolOf(sym, context)

Leads to a cyclic error compiling Specs2 under Scala 2.11.0, which tries to initialize sym.owner if !currentRun.compiles(sym.owner).

That check is buggy in the compiler.

Here's the error I saw:

7: illegal cyclic reference involving type l
[error] case class RightCheckedMatcher[T](check: ValueCheck[T]) extends OptionLikeCheckedMatcher[({type l[a]=Either[_, a]})#l, T]("Right", (_:Either[Any, T]).right.toOption, check)
[error]                                                                                                             ^
[error] /Users/jason/code/specs2/matcher/src/main/scala/org/specs2/matcher/EitherMatchers.scala:46: illegal cyclic reference involving type l
[error] case class RightMatcher[T]() extends OptionLikeMatcher[({type l[a]=Either[_, a]})#l, T]("Right", (_:Either[Any, T]).right.toOption)
[error]                                                                           ^
[error] /Users/jason/code/specs2/matcher/src/main/scala/org/specs2/matcher/EitherMatchers.scala:50: illegal cyclic reference involving type l
[error] case class LeftCheckedMatcher[T](check: ValueCheck[T]) extends OptionLikeCheckedMatcher[({type l[a]=Either[a, _]})#l, T]("Left", (_:Either[T, Any]).left.toOption, check)
[error]                                                                                                               ^
[error] /Users/jason/code/specs2/matcher/src/main/scala/org/specs2/matcher/EitherMatchers.scala:49: illegal cyclic reference involving type l
[error] case class LeftMatcher[T]() extends OptionLikeMatcher[({type l[a]=Either[a, _]})#l, T]("Left", (_:Either[T, Any]).left.toOption)
[error]                                                                             ^
[info] Compiling 96 Scala sources to

Debug notes:

Context(EitherMatchers.scala) {
   owner       = type l
   tree        = ExistentialTypeTree:Either[_$2, a] forSome { <synthetic> type _$2 }
   scope       = 2 decls
   contextMode = AmbiguousErrors ImplicitsEnabled MacrosEnabled ReportErrors TypeConstructorAllowed
   outer.owner = type l
}

owner = type l
owner.enclosingTopLevelClass = <refinement of AnyRef>

You could workaround this by checking for !sym.owner.enclosingTopLevelClass.isRefinementClass before you try to call that, and submit a patch to the compiler to fold this into CurrentRun#compiles.

I noted another bug with compiles: https://issues.scala-lang.org/browse/SI-7758 that you should also try to guard against.

[retronym]

What's worse, is that the subproject (specs2-matcher) that exhibits the failure itself does not include the macro-paradise plugin. However, if the entire project is built, which includes specs2-matcher-extra that does add paradise as a compiler plugin, specs2-matcher is somehow compiled with the paradise namer.

[retronym]

This might be stemming from some aspect of SBT's compiler caching, I'm checking with @harrah

[retronym]

I'm working with: retronym/specs2@f75bc21

[retronym]

I found the SBT problem: the specs2 build defined an überproject that aggregates the sources/classpaths of all others. That's why saw paradise involved in compiling sources from other modules.

That said, this goes to highlight a funny problem with hacks/hijacking etc: it is much harder to know what to trust and who to blame. Even when the hack isn't to blame, it is! :)

[xeno-by]

@retronym Thank you for the detailed investigation. Indeed, using paradise here led to unpredictable effects. How could we guard ourselves against them in the future?

[retronym]

• use paradise only where needed. @etorreborre did all the work to get there with his internal modularization, the one residual problem is the überbuild that he has a a backwards compatibility mechanism for users that still want the one-big-JAR. I will submit a patch to his build that lets us remove that module altogether with a flag, and we'll use that to get our integration builds working.
• be cautious calling companionSymbol -- only do so for symbols that might have companions

[xeno-by]

Are you in Lausanne now? I could drop by, so that we could decide what immediate steps should be taken on my side.

[retronym]

Still a few hours away. I'll drop by when I get there.

[retronym]

Specs PR: etorreborre/specs2#217

[retronym]

The good news is that the standard 2.11 compiler is sufficient to build Specs; we just needed to conditionally disable macro-paradise. This shows that the effort to keep quasiquotes in from scala/scala in sync with those in paradise is worthwhile.

[xeno-by]

@retronym @densh Maybe it would make sense to backport quasiquotes to 2.10.x?

[retronym]

Didn't we have binary compatibility shackles that prevented that?

[xeno-by]

@retronym We did, but maybe we can lift them, because in this particular case only compile time is affected, not runtime. What do you think? /cc @adriaanm

[retronym]

I think we're better off focusing our attentions on 2.11 at this point.

[adriaanm]

What Jason said.

[xeno-by]

Fixed in 22c6bad