file:bONJJAyker4PSMacwqjQYw
multi-module sbt build with sbt-eclipse

Nice clean and concise test data. Thanks a lot.

@jzaugg says:

> AFAICS, the compiler leaves a trace of the unexpanded macro as a tree attachment. See: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/StdAttachments.scala#L40
> So the IDE ought to 'unexpand' macros when performing navigation, usage search, refactoring etc.

@jzaugg unfortunately it's not very easy to use that information. The reason is that the expanded macro receives an OffsetPosition, meaning that the presentation compiler returns the outer tree. The first idea, to walk down the tree and find any macro expansions, and use the original tree instead, fails for cases like this one:

val x = aMacro.toDouble // hyperlink on toDouble

hyperlinking on either `aMacro` or `toDouble` returns the same tree -> `Select(<expanded macro>, "toDouble"). I can't distinguish between the two cases, so I don't know if I should jump to `aMacro` or `toDouble`.

@idragos, so this is ultimately presentation compiler bug because it returns you the same tree, right?

Here is how the reflection library undoes macro expansion. This is done in the `reify` macro.

    private def undoMacroExpansion(tree: Tree): Tree =
      tree.attachments.get[MacroExpansionAttachment] match {
        case Some(MacroExpansionAttachment(original)) =>
          def mkImplicitly(tp: Type) = atPos(tree.pos)(
            gen.mkNullaryCall(Predef_implicitly, List(tp))
          )
          val sym = original.symbol
          original match {
            // this hack is necessary until I fix implicit macros
            // so far tag materialization is implemented by sneaky macros hidden in scala-compiler.jar
            // hence we cannot reify references to them, because noone will be able to see them later
            // when implicit macros are fixed, these sneaky macros will move to corresponding companion objects
            // of, say, ClassTag or TypeTag
            case Apply(TypeApply(_, List(tt)), _) if sym == materializeClassTag            => mkImplicitly(appliedType(ClassTagClass, tt.tpe))
            case Apply(TypeApply(_, List(tt)), List(pre)) if sym == materializeWeakTypeTag => mkImplicitly(typeRef(pre.tpe, WeakTypeTagClass, List(tt.tpe)))
            case Apply(TypeApply(_, List(tt)), List(pre)) if sym == materializeTypeTag     => mkImplicitly(typeRef(pre.tpe, TypeTagClass, List(tt.tpe)))
            case _                                                                         => original
          }
        case _ => tree
      }

Well, it functions according to specification :). The problem is that the qualifier (expanded macro) under `Select` has an offset position, so it can't be returned by the PC.

@idragos, what I'm trying to ask is whether PC should call `undoMacroExpansion` @jason.zaugg quoted above in case it detects that the tree has `MacroExpansionAttachment` attachment? This way PC could return a tree with range positions.

Yes, I think that might work. Of course, that method needs to migrate to some place where it's accessible, but it looks good.

@idragos: What do you mean by accessible? I'd assume that calls to `undoMacroExpansion` would be fully encapsulated in presentation compiler and transparent to its clients when they call various ask methods. Do you have anything else in mind?

It's private now.

I know, but I'm asking if you want to expose it just to presentation compiler internals or make it accessible to presentation compiler clients?

Also, could you point me at an example of presentation compiler test that I could use as basis for test for hyperlinking of trees that contain macro invocations?

https://github.com/scala/scala/tree/master/test/files/presentation/hyperlinks

But it will be hard to write a self-contained test (the framework does not build anything, it only tests the presentation compiler). If you have a jar with macros already, then it should be easy. Some docs on how the test framework operates are here: http://scala-ide.org/docs/dev/testing/presentation-compiler-tests.html

I'm trialling an idea in scala-async to return the unexpanded tree after the macro has run in the IDE: https://github.com/scala/async/pull/46

I hope we can generalize this technique into something that makes all macros IDE friendly.

Your proposal is that instead of walking trees in both macro expansion and original macro application we would just keep macro application unexpanded when presentation compiler runs, right?

Do I understand that you say we would generalize this technique so all blackbox macros become IDE friendly?
Do we want to expose the fact that given macro is expanded by presentation compiler to the macro author?

Also, we would like to have an ability to expand macros when hovered over them or when user clicks on a button. For that feature to work we would need a separate typechecker instance that does expand macros, right?

There are a range of options.

1. Do we expand blackbox macros at all?

If we don't:
+ hyperlinking and other editing features will work without additional effort
+ macros can't impact the responsiveness of the IDE
- we lose macro specific warnings/errors
- (?) the debugger might be confused when debugging the expansion.

2. If we do expand macros, do we:
a) put the expansion in the tree with the original as an attachment (as is done today)
b) discard the expansion, as I am trailling in scala-async
c) do the opposite of a), leaving the original, well positioned trees in place, exposing the expansion as an attachment.

a) would require IDE changes to as originally discussed in this ticket to change the navigation code to be macro attachment aware
c) would require IDE changes only for your proposed "show expansion" button

One problem with b) and c) arises with nested macros. In the code below, would `macro1` see the expansion of `macro2()`? Some macros might rely on that.

macro1 { macro2() }

@xeno_by What do we do with whitebox macros? Let's assume that we expand the macro, we still have some latitude as to what trees we present to the IDE. For instance, we could run the macro to compute the type, and then `setType` to refine the type of the macro application which is left in the tree. (similar to 2.b above)

I suggest that we don't give up support for whitebox macros in the IDE, but rather identify and fix the problems with IDE integration that we have today.

From what I see these are:
1) Hyperlinking not working for macro applications.
2) Potential for degradation of responsiveness of the IDE.
3) Opaqueness of macro expansions to IDE users.
4) Lack of integration with the debugger.

I am positive that for def macros all these problems can be solved without requiring blackboxity, so let's just decide on the timeframe, and I will personally see to it. Also, as we discussed with Vojin and Iulian before, Vojin's student plans to work on IDE integration as well, so we should have enough resources to implement the required functionality.

Therefore I suggest that we meet next week on Thursday during the reflection meeting (or the core meeting, whichever suits everyone better) and discuss the work items along with the concrete dates.

This is actually a part of a bigger discussion that I wanted to start somewhen before this year ends, the one about our plans to stabilize some subset of macros in 2.12. Let's figure out what needs to be done towards that goal and set the deadlines for that as well.

@xeno_by: adding good support for blackbox macros first doesn't imply support for whitebox can't be added later on. The list of issues you outlined will require a lot of work to address so it's better that we start with smaller scope and deliver fixes faster to our users.

If adding support for blackbox macros turns out to be really easy that's only better: you have more time to add support for whitebox macros :-)

Also, I'd prefer to keep our discussions here where everybody (including IDE team) has an access to.

@gkossakowski: removing something is much easier than adding it back later, so let's first try to see whether we can avoid removals.

Allright, let's discuss online, I don't mind that. What kinds of timeframes are we talking about wrt the four problems I outlined above?

I'd like to have (at least) black box macros working well in the IDE with Scala 2.11. Not sure where the changes will be needed for that (IDE / Pres Compiler / Macro Engine?), but it is highly likely that we'll need some in scala/scala, so we should nail it down by, say, Christmas.

I don't think I can fix everything by the milestone you propose. How about we start with problem 1 and get it fixed by 25 Dec?

I think we should have an option whether to expand macros or not. And yes, hyperlinking is the highest priority right now, so it looks like a good first step

Yes, that's the one I'm most interested in tackling. I think we could also do #2 in a technically straightforward manner with `-Yno-blackbox-expand`, mapped to an IDE option.

Also, the option to disable blackbox expansion can help people workaround hitherto undiscovered bugs.

So if by 25 Dec we have:
1) Working hyperlinking in the IDE (regardless of how its implemented)
2) The "Disable macro expansion" checkbox unchecked by default (only for critical situations when some previously unknown critical bug emerges)
3) (Maybe) a watchdog inside the compiler that monitors how much time macro expansions take,

Then we're all good, and nothing else needs to be changed, right?

> One problem with b) and c) arises with nested macros. In the code below, would `macro1` see the expansion of `macro2()`? Some macros might rely on that.
> macro1 { macro2() }

@jason.zaugg: so macro1 wouldn't see what macro2 expanded to. However, macro2 would still be typechecked so macro1 can inspect it's type. The only thing which would fail is that macro1 relies on structural checks of the tree and issues errors/warnings based on those checks. In that case, we would miss them. However, presentation compiler already misses some other common errors (e.g. refchecks) then I think it's not a big deal. All those errors would be reported using batch compiler anyway.

Therefore I'd vote for not expanding macros at all in presentation compiler and just typechecking them.

WDYT?

It could also happen the other way around: the outer macro would issue a spurious error if the inner macro wasn't expanded (again, based on tree shapes, not on types).

We also need to consider the debugger: would it prefer expanded trees, unexpanded, or is it agnostic?

Some experimentation is needed to find the right solution. Black box macros offer us a good spectrum of solutions here.

@gkossakowski @jason.zaugg I understand the desire to prioritize blackbox macros, but I think that here we can support both box flavors by the deadline that's been set.

How about we start with https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001449-code-navigation-fails-when-macros-are-used?comment=405443283#comment:405443283, and then after it's done, decide whether we need to disable support for whitebox macros?

Yep, sounds great.

I've started work on this: https://github.com/retronym/scala/compare/topic;pres-compiler-macros?expand=1

We've just merged the changes into 2.11.x

https://github.com/scala/scala/pull/3342

I would appreciate if a member of the IDE team would try this out in Eclipse and confirm that this bug is fully fixed.

Looks like it's working!

However, the first time I tried, I got a compiler crash, something like: "presentation compiler crashed during macro expansion". But I couldn't reproduce it. ALso, I've seen the following stacktrace in the Error Log, but I cannot say for sure if it's related to the crash I mentioned:

scala.reflect.internal.FatalError: bad macro impl binding: macroEngine is supposed to be there
	at scala.reflect.internal.SymbolTable.abort(SymbolTable.scala:56)
	at scala.tools.nsc.Global.abort(Global.scala:263)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.fail$1(Macros.scala:227)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.failField$1(Macros.scala:229)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.unpickle$1(Macros.scala:230)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.unpickle(Macros.scala:239)
	at scala.tools.nsc.typechecker.Macros$$anonfun$loadMacroImplBinding$1.applyOrElse(Macros.scala:258)
	at scala.tools.nsc.typechecker.Macros$$anonfun$loadMacroImplBinding$1.applyOrElse(Macros.scala:257)
	at scala.PartialFunction$Lifted.apply(PartialFunction.scala:218)
	at scala.PartialFunction$Lifted.apply(PartialFunction.scala:214)
	at scala.tools.nsc.typechecker.Macros$class.loadMacroImplBinding(Macros.scala:257)
	at scala.tools.nsc.interactive.Global$$anon$5.loadMacroImplBinding(Global.scala:221)
	at scala.reflect.macros.runtime.MacroRuntimes$MacroRuntimeResolver.<init>(MacroRuntimes.scala:54)
	at scala.reflect.macros.runtime.MacroRuntimes$$anonfun$standardMacroRuntime$3.apply(MacroRuntimes.scala:35)
	at scala.reflect.macros.runtime.MacroRuntimes$$anonfun$standardMacroRuntime$3.apply(MacroRuntimes.scala:35)
	at scala.collection.mutable.MapLike$class.getOrElseUpdate(MapLike.scala:188)
	at scala.collection.mutable.AbstractMap.getOrElseUpdate(Map.scala:92)
	at scala.reflect.macros.runtime.MacroRuntimes$class.standardMacroRuntime(MacroRuntimes.scala:35)
	at scala.tools.nsc.interactive.Global$$anon$5.standardMacroRuntime(Global.scala:221)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$$anon$11.default(AnalyzerPlugins.scala:398)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$$anon$11.default(AnalyzerPlugins.scala:395)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$class.invoke(AnalyzerPlugins.scala:359)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$class.pluginsMacroRuntime(AnalyzerPlugins.scala:395)
	at scala.tools.nsc.interactive.Global$$anon$5.pluginsMacroRuntime(Global.scala:221)
	at scala.reflect.macros.runtime.MacroRuntimes$class.macroRuntime(MacroRuntimes.scala:22)
	at scala.tools.nsc.interactive.Global$$anon$5.macroRuntime(Global.scala:221)
	at scala.tools.nsc.typechecker.Macros$MacroExpander$$anonfun$expand$1.apply(Macros.scala:560)
	at scala.tools.nsc.typechecker.Macros$MacroExpander$$anonfun$expand$1.apply(Macros.scala:554)
	at scala.tools.nsc.Global.withInfoLevel(Global.scala:192)
	at scala.tools.nsc.typechecker.Macros$MacroExpander.expand(Macros.scala:553)
	at scala.tools.nsc.typechecker.Macros$MacroExpander.apply(Macros.scala:541)
	at scala.tools.nsc.typechecker.Macros$class.standardMacroExpand(Macros.scala:700)

I'm in a hurry now, but will try again on Monday.

Looks like an incompatibility between the old and the new versions of the macro engine. Is everything in the toolchain using the new snapshot build of 2.11.0?

I don't think so. We'll need a new build of async.

Is there a chance to make this backwards compatible? One of our goals for Scala 2.11.0 is that you can use an IDE built with to (presentation) typecheck run your 2.10 projects.

That's equivalent to `scalac211 -Xsource:2.10 -Ystop-after:typer -classpath:<2.10-libs> <2.10 sources>`

Francois has a PR open at the moment that introduces the -Xsource flag that lets us predicate incompatible changes to the language and even bug fixes.

I think it is possible. Please let me know when -Xsource is merged, and I will provide a necessary patch.

@xeno_by Scala version I used is 2.11.0-20140109-134332-e089cafb5f, and the IDE toolchain was entirely built on top of this version. Which makes me say it can't be an incompatibility.

Getting back to the above stacktrace, I have an additional, related, error in Eclipse:

scala.reflect.internal.FatalError: 
  bad macro impl binding: macroEngine is supposed to be there
     while compiling: /Users/mirco/Documents/workspace/p2/src/p2/Test.scala
        during phase: typer
     library version: version 2.11.0-20140109-134332-e089cafb5f
    compiler version: version 2.11.0-20140109-134332-e089cafb5f
  reconstructed args: -encoding US-ASCII -bootclasspath /Applications/dev-tools/eclipse 2/plugins/org.scala-lang.scala-library_2.11.0.v20140109-134332-e089cafb5f.jar -deprecation -javabootclasspath /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/Extensions/AppleScriptEngine.jar:/System/Library/Java/Extensions/dns_sd.jar:/System/Library/Java/Extensions/j3daudio.jar:/System/Library/Java/Extensions/j3dcore.jar:/System/Library/Java/Extensions/j3dutils.jar:/System/Library/Java/Extensions/jai_codec.jar:/System/Library/Java/Extensions/jai_core.jar:/System/Library/Java/Extensions/mlibwrapper_jai.jar:/System/Library/Java/Extensions/MRJToolkit.jar:/System/Library/Java/Extensions/QTJava.zip:/System/Library/Java/Extensions/vecmath.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/apple_provider.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/dnsns.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/localedata.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/sunjce_provider.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext/sunpkcs11.jar -classpath /Users/mirco/Documents/workspace/p2/bin:/Applications/dev-tools/eclipse 2/plugins/org.scala-lang.scala-reflect_2.11.0.v20140109-134332-e089cafb5f.jar:/Applications/dev-tools/eclipse 2/plugins/org.scala-lang.scala-actors_2.11.0.v20140108-111708-4e4c15177b.jar:/Applications/dev-tools/eclipse 2/configuration/org.eclipse.osgi/bundles/266/1/.cp/target/lib/scala-swing.jar:/Users/mirco/Documents/workspace/p1/bin

  last tree to typer: ApplyImplicitView(method augmentString)
       tree position: line 5 of /Users/mirco/Documents/workspace/p2/src/p2/Test.scala
            tree tpe: scala.collection.immutable.StringOps
              symbol: implicit method augmentString in object Predef
   symbol definition: implicit def augmentString(x: String): scala.collection.immutable.StringOps (a MethodSymbol)
      symbol package: scala
       symbol owners: method augmentString -> object Predef
           call site: object Test in package p2 in package p2

== Source file context for tree position ==

     2 object Test {
     3   p1.Macro {
     4     "".reverse
     5   }
     6 }
     7 // Was: a range position validation error (tree with offset position enclosing tree with range position)
	at scala.reflect.internal.SymbolTable.abort(SymbolTable.scala:56)
	at scala.tools.nsc.Global.abort(Global.scala:263)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.fail$1(Macros.scala:227)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.failField$1(Macros.scala:229)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.unpickle$1(Macros.scala:230)
	at scala.tools.nsc.typechecker.Macros$MacroImplBinding$.unpickle(Macros.scala:239)
	at scala.tools.nsc.typechecker.Macros$$anonfun$loadMacroImplBinding$1.applyOrElse(Macros.scala:258)
	at scala.tools.nsc.typechecker.Macros$$anonfun$loadMacroImplBinding$1.applyOrElse(Macros.scala:257)
	at scala.PartialFunction$Lifted.apply(PartialFunction.scala:218)
	at scala.PartialFunction$Lifted.apply(PartialFunction.scala:214)
	at scala.tools.nsc.typechecker.Macros$class.loadMacroImplBinding(Macros.scala:257)
	at scala.tools.nsc.Global$$anon$1.loadMacroImplBinding(Global.scala:453)
	at scala.reflect.macros.runtime.MacroRuntimes$MacroRuntimeResolver.<init>(MacroRuntimes.scala:54)
	at scala.reflect.macros.runtime.MacroRuntimes$$anonfun$standardMacroRuntime$3.apply(MacroRuntimes.scala:35)
	at scala.reflect.macros.runtime.MacroRuntimes$$anonfun$standardMacroRuntime$3.apply(MacroRuntimes.scala:35)
	at scala.collection.mutable.MapLike$class.getOrElseUpdate(MapLike.scala:188)
	at scala.collection.mutable.AbstractMap.getOrElseUpdate(Map.scala:92)
	at scala.reflect.macros.runtime.MacroRuntimes$class.standardMacroRuntime(MacroRuntimes.scala:35)
	at scala.tools.nsc.Global$$anon$1.standardMacroRuntime(Global.scala:453)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$$anon$11.default(AnalyzerPlugins.scala:398)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$$anon$11.default(AnalyzerPlugins.scala:395)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$class.invoke(AnalyzerPlugins.scala:359)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$class.pluginsMacroRuntime(AnalyzerPlugins.scala:395)
	at scala.tools.nsc.Global$$anon$1.pluginsMacroRuntime(Global.scala:453)
	at scala.reflect.macros.runtime.MacroRuntimes$class.macroRuntime(MacroRuntimes.scala:22)
	at scala.tools.nsc.Global$$anon$1.macroRuntime(Global.scala:453)
	at scala.tools.nsc.typechecker.Macros$MacroExpander$$anonfun$expand$1.apply(Macros.scala:560)
	at scala.tools.nsc.typechecker.Macros$MacroExpander$$anonfun$expand$1.apply(Macros.scala:554)
	at scala.tools.nsc.Global.withInfoLevel(Global.scala:192)
	at scala.tools.nsc.typechecker.Macros$MacroExpander.expand(Macros.scala:553)
	at scala.tools.nsc.typechecker.Macros$MacroExpander.apply(Macros.scala:541)
	at scala.tools.nsc.typechecker.Macros$class.standardMacroExpand(Macros.scala:700)
	at scala.tools.nsc.Global$$anon$1.standardMacroExpand(Global.scala:453)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$$anon$9.default(AnalyzerPlugins.scala:382)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$$anon$9.default(AnalyzerPlugins.scala:379)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$class.invoke(AnalyzerPlugins.scala:359)
	at scala.tools.nsc.typechecker.AnalyzerPlugins$class.pluginsMacroExpand(AnalyzerPlugins.scala:379)
	at scala.tools.nsc.Global$$anon$1.pluginsMacroExpand(Global.scala:453)
	at scala.tools.nsc.typechecker.Macros$class.macroExpand(Macros.scala:693)
	at scala.tools.nsc.Global$$anon$1.macroExpand(Global.scala:453)
	at scala.tools.nsc.typechecker.Typers$Typer.vanillaAdapt$1(Typers.scala:1105)
	at scala.tools.nsc.typechecker.Typers$Typer.adapt(Typers.scala:1160)
	at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5352)
	at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5365)
	at scala.tools.nsc.typechecker.Typers$Typer.body$2(Typers.scala:5312)
	at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5316)
	at scala.tools.nsc.typechecker.Typers$Typer.typedByValueExpr(Typers.scala:5394)
	at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedStat$1(Typers.scala:3016)
	at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$64.apply(Typers.scala:3120)
	at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$64.apply(Typers.scala:3120)
	at scala.collection.immutable.List.loop$1(List.scala:172)
	at scala.collection.immutable.List.mapConserve(List.scala:188)
	at scala.tools.nsc.typechecker.Typers$Typer.typedStats(Typers.scala:3120)
	at scala.tools.nsc.typechecker.Typers$Typer.typedTemplate(Typers.scala:1923)
	at scala.tools.nsc.typechecker.Typers$Typer.typedModuleDef(Typers.scala:1784)
	at scala.tools.nsc.typechecker.Typers$Typer.typedMemberDef$1(Typers.scala:5252)
	at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:5301)
	at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5338)
	at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5365)
	at scala.tools.nsc.typechecker.Typers$Typer.body$2(Typers.scala:5312)
	at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5316)
	at scala.tools.nsc.typechecker.Typers$Typer.typedByValueExpr(Typers.scala:5394)
	at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedStat$1(Typers.scala:3016)
	at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$64.apply(Typers.scala:3120)
	at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$64.apply(Typers.scala:3120)
	at scala.collection.immutable.List.loop$1(List.scala:172)
	at scala.collection.immutable.List.mapConserve(List.scala:188)
	at scala.tools.nsc.typechecker.Typers$Typer.typedStats(Typers.scala:3120)
	at scala.tools.nsc.typechecker.Typers$Typer.typedPackageDef$1(Typers.scala:4961)
	at scala.tools.nsc.typechecker.Typers$Typer.typedMemberDef$1(Typers.scala:5254)
	at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:5301)
	at scala.tools.nsc.typechecker.Typers$Typer.runTyper$1(Typers.scala:5338)
	at scala.tools.nsc.typechecker.Typers$Typer.scala$tools$nsc$typechecker$Typers$Typer$$typedInternal(Typers.scala:5365)
	at scala.tools.nsc.typechecker.Typers$Typer.body$2(Typers.scala:5312)
	at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5316)
	at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:5390)
	at scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$3.apply(Analyzer.scala:102)
	at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:424)
	at scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$3$$anonfun$run$1.apply(Analyzer.scala:94)
	at scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$3$$anonfun$run$1.apply(Analyzer.scala:93)
	at scala.collection.Iterator$class.foreach(Iterator.scala:743)
	at scala.collection.AbstractIterator.foreach(Iterator.scala:1174)
	at scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$3.run(Analyzer.scala:93)
	at scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1603)
	at scala.tools.nsc.Global$Run.compileUnits(Global.scala:1588)
	at scala.tools.nsc.Global$Run.compileSources(Global.scala:1583)
	at scala.tools.nsc.Global$Run.compile(Global.scala:1681)
	at xsbt.CachedCompiler0.run(CompilerInterface.scala:123)
	at xsbt.CachedCompiler0.run(CompilerInterface.scala:99)
	at xsbt.CompilerInterface.run(CompilerInterface.scala:27)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sbt.compiler.AnalyzingCompiler.call(AnalyzingCompiler.scala:102)
	at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:48)
	at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:41)
	at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply$mcV$sp(AggressiveCompile.scala:98)
	at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply(AggressiveCompile.scala:98)
	at sbt.compiler.AggressiveCompile$$anonfun$3$$anonfun$compileScala$1$1.apply(AggressiveCompile.scala:98)
	at sbt.compiler.AggressiveCompile.sbt$compiler$AggressiveCompile$$timed(AggressiveCompile.scala:159)
	at sbt.compiler.AggressiveCompile$$anonfun$3.compileScala$1(AggressiveCompile.scala:97)
	at sbt.compiler.AggressiveCompile$$anonfun$3.apply(AggressiveCompile.scala:142)
	at sbt.compiler.AggressiveCompile$$anonfun$3.apply(AggressiveCompile.scala:86)
	at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:38)
	at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:36)
	at sbt.inc.Incremental$.cycle(Incremental.scala:73)
	at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:33)
	at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:32)
	at sbt.inc.Incremental$.manageClassfiles(Incremental.scala:41)
	at sbt.inc.Incremental$.compile(Incremental.scala:32)
	at sbt.inc.IncrementalCompile$.apply(Compile.scala:26)
	at sbt.compiler.AggressiveCompile.compile2(AggressiveCompile.scala:150)
	at sbt.compiler.AggressiveCompile.compile1(AggressiveCompile.scala:70)
	at sbt.compiler.AggressiveCompile.apply(AggressiveCompile.scala:45)
	at sbt.compiler.IC$.compile(IncrementalCompiler.scala:22)
	at scala.tools.eclipse.buildmanager.sbtintegration.EclipseSbtBuildManager.runCompiler(EclipseSbtBuildManager.scala:138)
	at scala.tools.eclipse.buildmanager.sbtintegration.EclipseSbtBuildManager.update(EclipseSbtBuildManager.scala:129)
	at scala.tools.eclipse.buildmanager.sbtintegration.EclipseSbtBuildManager.build(EclipseSbtBuildManager.scala:175)
	at scala.tools.eclipse.ScalaProject.build(ScalaProject.scala:568)
	at scala.tools.eclipse.ScalaBuilder.build(ScalaBuilder.scala:129)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

Furthermore, the stacktrace I reported in my previous comment originated AT: RangePosition(/Users/mirco/Documents/workspace/p2/src/p2/Test.scala, 28, 37, 57)

I've attached to this ticket the two Eclipse projects I used to cause the issue.

Last but not least, I also see the presentation compiler reports an incorrect error because it can't resolve a symbol for package `p1` in source p2/Test.scala (see image attached to this ticket). Oddly, hyperlinking to Macro works fine, which is surprising to me, given the reported error.

presentation compiler confused - missing package symbol

file:cY8za4FcWr441GacwqjQYw
Eclipse projects used to produce the error reported in my comments

So, it looks like we have Trees that do not rfespect the range position invariants.

Can't reproduce the crash. Could it be that you had stale classfiles produced by the old version of the compiler on the classpath or something like that?

upd. Using Juno and the latest nightly for 2.11.x.

@xeno_by That's indeed possible, as I noticed the exception right after upgrading. However, the "missing package symbol" error happened later on, so I would say it's not caused by stale classfiles. But it may be hard to reproduce...

Yeah, I couldn't reproduce it either.

Ticket assignment reverted due to inactivity.