From 7d03dcc45ff3b892bc5db8c9f334697c103e767a Mon Sep 17 00:00:00 2001 From: Jason Zaugg Date: Sat, 16 Mar 2013 16:26:32 +0100 Subject: SI-7259 Fix detection of Java defined Selects The fix for SI-3120, 3ff7743, introduced a fallback within `typedSelect` that accounted for the ambiguity of a Java selection syntax. Does `A.B` refer to a member of the type `A` or of the companion object `A`? (The companion object here is a fiction used by scalac to group the static members of a Java class.) The fallback in `typedSelect` was predicated on `context.owner.enclosingTopLevelClass.isJavaDefined`. However, this was incorrectly including Select-s in top-level annotations in Scala files, which are owned by the enclosing package class, which is considered to be Java defined. This led to nonsensical error messages ("type scala not found.") Instead, this commit checks the compilation unit of the context, which is more direct and correct. (As I learned recently, `currentUnit.isJavaDefined` would *not* be correct, as a lazy type might complete a Java signature while compiling some other compilation unit!) A bonus post factum test case is included for SI-3120. Manual forward port of f046853 which was not merged as part of the routine 2.10.x to master merge. The test case uncovered a NullPointerExceptiion crasher in annotation typechecking introduced in 5878099c; this has been prevented with a null check. Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala --- src/compiler/scala/tools/nsc/typechecker/Typers.scala | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'src/compiler/scala/tools/nsc/typechecker/Typers.scala') diff --git a/src/compiler/scala/tools/nsc/typechecker/Typers.scala b/src/compiler/scala/tools/nsc/typechecker/Typers.scala index 0e57145343..7cbae17bd9 100644 --- a/src/compiler/scala/tools/nsc/typechecker/Typers.scala +++ b/src/compiler/scala/tools/nsc/typechecker/Typers.scala @@ -3558,7 +3558,7 @@ trait Typers extends Adaptations with Tags { // If there are dummy type arguments in typeFun part, it suggests we // must type the actual constructor call, not only the select. The value // arguments are how the type arguments will be inferred. - if (targs.isEmpty && typedFun0.exists(t => isDummyAppliedType(t.tpe))) + if (targs.isEmpty && typedFun0.exists(t => t.tpe != null && isDummyAppliedType(t.tpe))) logResult(s"Retyped $typedFun0 to find type args")(typed(argss.foldLeft(fun0)(Apply(_, _)))) else typedFun0 @@ -4692,7 +4692,9 @@ trait Typers extends Adaptations with Tags { def handleMissing: Tree = { def errorTree = missingSelectErrorTree(tree, qual, name) def asTypeSelection = ( - if (context.owner.enclosingTopLevelClass.isJavaDefined && name.isTypeName) { + if (context.unit.isJava && name.isTypeName) { + // SI-3120 Java uses the same syntax, A.B, to express selection from the + // value A and from the type A. We have to try both. atPos(tree.pos)(gen.convertToSelectFromType(qual, name)) match { case EmptyTree => None case tree1 => Some(typed1(tree1, mode, pt)) -- cgit v1.2.3