summaryrefslogtreecommitdiff
path: root/src/compiler
Commit message (Collapse)AuthorAgeFilesLines
* SI-6484 adds Universe.typeOf[T](x: T)Eugene Burmako2014-02-142-2/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a nice addition to Universe.typeOf[T], quite frequently useful for inspecting ad-hoc types. As promised by https://github.com/scala/scala/pull/1741, which represented my previous stab at adding this API, I ran into problems when trying to introduce the API naively. def typeOf[T](implicit ttag: TypeTag[T]): Type def typeOf[T: TypeTag](x: T): Type The first problem came from the fact that even though they don't look ambiguous, under certain circumstances, the couple of typeOf overloads can become ambiguous. Concretely, ambiguity happens when T <: TypeTag[T], which makes the compiler uncapable to choose an overload to typecheck `typeOf[T](<materialized>: TypeTag[T])`. Luckily, defining x as a by-name parameter fixes the problem. def typeOf[T](implicit ttag: TypeTag[T]): Type def typeOf[T: TypeTag](x: => T): Type The second problem manifested itself in reification of snippets that contained calls to typeOf. Apparently, materialized tags get rolled back by reify as products of macro expansion, becoming replaced with `implicitly[TypeTag[T]]`. Afterwards, subsequent rollback of TypeTree's strips the replacement of its type argument, producing bare `implicitly`. Back then when typeOf wasn't overloaded, this abomination typechecked and worked correctly, but now, due to some weird reason, it stopped. I have worked around this by performing the rollback on a larger scale - instead of hunting down materialized tags, this commit detects calls to typeOf and removes their implicit argument lists altogether.
* SI-8192 adds ClassSymbol.isPrimaryConstructorEugene Burmako2014-02-141-4/+4
| | | | | | | | | | | | | | | | | | | | | Exposes a popular code pattern in macros as a dedicated reflection API. This simple commit, however, ended up being not so simple, as it often happens with our compiler. When writing a test for the new API, I realized that our (pre-existing) MethodSymbol.isPrimaryConstructor API returns nonsensical results for implementation artifacts (trait mixin ctors, module class ctors). What’s even more funny is that according to our reflection internals, even Java classes have primary constructors. Well, that’s not surprising, because `primaryConstructor` is just `decl(ctorName).alternatives.head`. Good thing that package classes don’t have constructors or that would elevate the situation to three fries short of a happy meal. At the moment, I’m too scared to fiddle with internal#Symbol.primaryConstructor, because that could easily break someone right before RC1, so I simply documented the findings in SI-8193 and postponed the actual work, except for one thing - isJavaDefined symbols no longer have primary constructors.
* additional class tags for reflection APIEugene Burmako2014-02-143-0/+15
| | | | | | | | | Introduces a test that iterates all abstract types in reflection API and makes sure that every one of them has an associated class tag. After being introduced, the test has immediately failed exposing the lack of tags for TreeCopier, Mirror and RuntimeClass, which has been subsequently fixed in this commit.
* proceeds with the quest of removing `local` from namesEugene Burmako2014-02-126-48/+52
| | | | | Continuing in the direction set by the parent commit, this commit rephrases some more usages of `local` in names and comments in typer.
* disambiguates uses of “local” in internal symbol APIEugene Burmako2014-02-1213-38/+34
| | | | | | | | | | | | | | | | | There’s been a conflation of two distinct meanings of the word “local” in the internal symbol API: the first meaning being “local to this” (as in has the LOCAL flag set), the second meaning being “local to block” (as in declared in a block, i.e. having owner being a term symbol). Especially confusing is the fact that sym.isLocal isn’t the same as sym.hasFlag(LOCAL), which has led to now fixed SI-6733. This commit fixes the semantic mess by deprecating both Symbol.isLocal and Symbol.hasLocalFlag (that we were forced to use, because Symbol.isLocal had already been taken), and replacing them with Symbol.isLocalToThis and Symbol.isLocalToBlock. Unfortunately, we can’t remove the deprecated methods right away, because they are used in SBT, so I had to take small steps.
* Merge pull request #3503 from adriaanm/rebase-3440Adriaan Moors2014-02-111-1/+6
|\ | | | | SI-7475 Private members aren't inheritable, findMember overhaul
| * SI-7475 Private members are not inheritableJason Zaugg2014-02-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out `findMembers` has been a bit sloppy in recent years and has returned private members from *anywhere* up the base class sequence. Access checks usually pick up the slack and eliminate the unwanted privates. But, in concert with the "concrete beats abstract" rule in `findMember`, the following mishap appeared: scala> :paste // Entering paste mode (ctrl-D to finish) trait T { def a: Int } trait B { private def a: Int = 0 } trait C extends T with B { a } // Exiting paste mode, now interpreting. <console>:9: error: method a in trait B cannot be accessed in C trait C extends T with B { a } ^ I noticed this when compiling Akka against JDK 8; a new private method in the bowels of the JDK was enough to break the build! It turns out that some finesse in needed to interpret SLS 5.2: > The private modifier can be used with any definition or declaration > in a template. They are not inherited by subclasses [...] So, can we simply exclude privates from all but the first base class? No, as that might be a refinement class! The following must be allowed: trait A { private def foo = 0; trait T { self: A => this.foo } } This commit: - tracks when the walk up the base class sequence passes the first non-refinement class, and excludes private members - ... except, if we are at a direct parent of a refinement class itself - Makes a corresponding change to OverridingPairs, to only consider private members if they are owned by the `base` Symbol under consideration. We don't need to deal with the subtleties of refinements there as that code is only used for bona-fide classes. - replaces use of `hasTransOwner` when considering whether a private[this] symbol is a member. The last condition was not grounded in the spec at all. The change is visible in cases like: // Old scala> trait A { private[this] val x = 0; class B extends A { this.x } } <console>:7: error: value x in trait A cannot be accessed in A.this.B trait A { private[this] val x = 0; class B extends A { this.x } } ^ // New scala> trait A { private[this] val x = 0; class B extends A { this.x } } <console>:8: error: value x is not a member of A.this.B trait A { private[this] val x = 0; class B extends A { this.x } } ^ Furthermore, we no longer give a `private[this]` member a free pass if it is sourced from the very first base class. trait Cake extends Slice { private[this] val bippy = () } trait Slice { self: Cake => bippy // BCS: Cake, Slice, AnyRef, Any } The different handling between `private` and `private[this]` still seems a bit dubious. The spec says: > An different form of qualification is private[this]. A member M > marked with this modifier can be accessed only from within the > object in which it is defined. That is, a selection p.M is only > legal if the prefix is this or O.this, for some class O enclosing > the reference. In addition, the restrictions for unqualified > private apply. This sounds like a question of access, not membership. If so, we should admit `private[this]` members from parents of refined types in `FindMember`. AFAICT, not too much rests on the distinction: do we get a "no such member", or "member foo inaccessible" error? I welcome scrutinee of the checkfile of `neg/t7475f.scala` to help put this last piece into the puzzle. One more thing: findMember does not have *any* code the corresponds to the last sentence of: > SLS 5.2 The modifier can be qualified with an identifier C > (e.g. private[C]) that must denote a class or package enclosing > the definition. Members labeled with such a modifier are accessible > respectively only from code inside the package C or only from code > inside the class C and its companion module (§5.4). > Such members are also inherited only from templates inside C. When I showed Martin this, he suggested it was an error in the spec, and we should leave the access checking to callers of that inherited qualified-private member.
* | Revert "SI-1786 incorporate defined bounds in inference"Adriaan Moors2014-02-111-16/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Have to revert because the stricter bounds that it inferred break e.g., slick. (Backstop for that added as pos/t1786-counter.scala, as minimized by Jason) Worse, the fix was compilation order-dependent. There's a less invasive fix (SI-6169) that could be generalized in `sharpenQuantifierBounds` (used in `skolemizeExistential`), but I'd rather not mess with existentials at this point. This reverts commit e28c3edda4dd405ed382227d2a688b799bf33c72. Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala test/files/pos/t1786.scala
* | Merge pull request #3495 from xeno-by/ticket/8209Jason Zaugg2014-02-111-3/+5
|\ \ | | | | | | changes the order of whitebox typechecks. yes, again.
| * | changes the order of whitebox typechecks. yes, again.Eugene Burmako2014-02-091-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My first attempt at SI-6992 was about having whitebox expansions first typecheck against outerPt and only then verify that the result is compatible with innerPt. That was a nice try, but soon after it went live in 2.11.0-M8, we've got multiple reports with problems - both shapeless and then in a week specs2 started having issues with their whitebox macros. In shapeless, typecheck against outerPt screwed up type inference, which was more or less fixable by explicit type annotations, so I decided to wait a bit before jumping to conclusions. However, in specs2 the problem was more insidious. After being typechecked against outerPt, expansions were being implicitly converted to a type that became incompatible with innerPt. This revealed a fatal flaw of the implemented approach - if allowed to typecheck against outerPt first, whitebox macros could never be robust. Now realizing that "outerPt > innerPt" doesn't work, I nevertheless wasn't looking forward to rolling that back to "innerPt > outerPt", because that would revive SI-6992 and SI-8048 that are highly unintuitive, especially the latter one. Therefore, this commit combines the permissiveness of "... > innerPt" approaches with the robustness of "innerPt > outerPt", introducing "WildcardType > innerPt > outerPt".
* | | Tweak parser entry point for pqDenys Shabalin2014-02-111-1/+1
| | | | | | | | | | | | | | | | | | Previously pq used pattern1 which required parens to be used in alternative pattern. This commit tweaks it to allow pq"a | b" syntax. Also adds some tests for alternative syntax.
* | | Merge pull request #3456 from soc/SI-8226Grzegorz Kossakowski2014-02-115-215/+233
|\ \ \ | |_|/ |/| | SI-8226 Deduplicate JavaTokens/ScalaTokens
| * | SI-8226 Deduplicate Scala's Tokens and JavaTokensSimon Ochsenreither2014-02-105-215/+233
| | |
* | | Merge pull request #3497 from adriaanm/rebase-3464Adriaan Moors2014-02-102-2/+4
|\ \ \ | | | | | | | | Make Object#== override Any#==
| * | | SI-8129 Crack the case of the curiously incoherent ContextJason Zaugg2014-02-102-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Typer is created with Context. - Typer creates an Inferencer with said Context. - Typer mutates Typer#context after each import statement - Typer mutates its current Context (e.g to disable implicits.) - Typer asks a question of Inferencer - Inferencer, looking at the old context, thinks that implicits are allowed - Inferencer saves implicit ambiguities into the wrong Context. Because of this bug, overload resolution in blocks or template bodies for applications that follow an import have been considering implicit coercions in the first try at static overload resolution, and, in the rare case that it encounters an ambigous implicit in the process, leaking an unpositioned ambiguout error. This commit ensures coherency between `typer.context` and `typer.infer.context` by making the latter delegate to the former.
* | | | Merge pull request #3502 from retronym/ticket/8258Grzegorz Kossakowski2014-02-101-0/+2
|\ \ \ \ | |/ / / |/| | | Fix regression for using Scala IDE on scala-library
| * | | SI-8258 Revert "SI-7335 Remove special case for import of Predef._Jason Zaugg2014-02-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 66904556ef34dc81cbb7c09257b013b3ddb76f78. Conflicts: src/reflect/scala/reflect/internal/TreeInfo.scala As evidenced by the highlights of the stack trace in Scala IDE, my assertion in the 66904556e wasn't universally true. The change was only motivated by removing a special case, not in order to fix some other problem. So the revert is the most straight forward course of action for now. I haven't pinned this down with a test outside of Eclipse, and given the lateness of the hour wrt 2.11.0, I'll have to submit without one. 2013-03-10 08:38:04,690 ERROR [main] - org.scala-ide.sdt.core - org.scala-ide.sdt.core - org.scala-ide.sdt.core - 0 - Error during askOption scala.reflect.internal.Symbols$CyclicReference: illegal cyclic reference involving object Predef ... at scala.reflect.internal.Symbols$Symbol.lock(Symbols.scala:482) at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1216) at scala.reflect.internal.Symbols$Symbol.tpe(Symbols.scala:1200) at scala.reflect.internal.Symbols$Symbol.tpeHK(Symbols.scala:1201) at scala.reflect.internal.Types$Type.computeMemberType(Types.scala:784) at scala.reflect.internal.Types$Type.memberType(Types.scala:781) at scala.reflect.internal.TreeGen.mkAttributedSelect(TreeGen.scala:203) ... at scala.reflect.internal.TreeGen.mkAttributedStableRef(TreeGen.scala:162) at scala.tools.nsc.ast.TreeGen.mkWildcardImport(TreeGen.scala:39) at scala.tools.nsc.typechecker.Contexts$Context.makeNewImport(Contexts.scala:308) at scala.tools.nsc.typechecker.Contexts$class.rootContext(Contexts.scala:69) at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492) at scala.tools.nsc.typechecker.Contexts$class.rootContext(Contexts.scala:64) at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492) at scala.tools.nsc.typechecker.Analyzer$namerFactory$$anon$1.apply(Analyzer.scala:43) at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:463) ... at scala.tools.nsc.Global$Run.compileLate(Global.scala:1681) at scala.tools.nsc.Global$Run.compileLate(Global.scala:1671) at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:284) at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:187) at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1229) at scala.reflect.internal.Symbols$Symbol.tpe(Symbols.scala:1200) at scala.reflect.internal.Symbols$Symbol.tpeHK(Symbols.scala:1201) at scala.reflect.internal.Types$Type.computeMemberType(Types.scala:784) at scala.reflect.internal.Types$Type.memberType(Types.scala:781) at scala.reflect.internal.TreeGen.mkAttributedSelect(TreeGen.scala:203) at scala.reflect.internal.TreeGen.mkAttributedRef(TreeGen.scala:124) at scala.reflect.internal.TreeGen.mkAttributedRef(TreeGen.scala:130) at scala.reflect.internal.TreeGen.mkAttributedStableRef(TreeGen.scala:162) at scala.tools.nsc.ast.TreeGen.mkWildcardImport(TreeGen.scala:39) ... at scala.tools.nsc.Global$$anon$1.rootContext(Global.scala:492) at scala.tools.nsc.typechecker.Analyzer$namerFactory$$anon$1.apply(Analyzer.scala:43) at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:463) ... at scala.tools.nsc.Global$Run.compileLate(Global.scala:1671) at scala.tools.nsc.symtab.SymbolLoaders$SourcefileLoader.doComplete(SymbolLoaders.scala:284) at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:187) at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1229) at scala.reflect.internal.Symbols$Symbol.initialize(Symbols.scala:1365) ... at scala.collection.immutable.HashSet$HashSet1.foreach(HashSet.scala:153) at scala.collection.immutable.HashSet$HashTrieSet.foreach(HashSet.scala:306) at scala.tools.eclipse.javaelements.ScalaJavaMapper$class.initializeRequiredSymbols(ScalaJavaMapper.scala:29) ... at scala.tools.nsc.util.InterruptReq.execute(InterruptReq.scala:26) at scala.tools.nsc.interactive.Global.pollForWork(Global.scala:340)
* | | | Merge pull request #3496 from adriaanm/t6169Grzegorz Kossakowski2014-02-101-0/+3
|\ \ \ \ | | | | | | | | | | SI-6169 TODO: consolidate with fix for SI-1786 (#2518)
| * | | | SI-6169 TODO: consolidate with fix for SI-1786 (#2518)Adriaan Moors2014-02-091-0/+3
| | | | |
* | | | | Merge pull request #3494 from retronym/topic/opt-any-ref-mapGrzegorz Kossakowski2014-02-105-7/+13
|\ \ \ \ \ | | | | | | | | | | | | Optimization: use AnyRef map for Namer -> Typer tree handoff
| * | | | | Optimation: use AnyRefMap in GenASM javaName cachesJason Zaugg2014-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | These are a hotspot in the backend.
| * | | | | Optimization: use AnyRef map for Namer -> Typer tree handoffJason Zaugg2014-02-094-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And uses a map per-compilation unit, rather than one per Typer. One small change required: we now need to clear this map in the the interactive compiler which reuses compilation units, rather than in the call to `Typer#reset`.
* | | | | | Merge pull request #3428 from retronym/ticket/6260Grzegorz Kossakowski2014-02-102-21/+36
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-6260 Avoid double-def error with lambdas over value classes
| * | | | | | SI-6260 Adddress pull request reviewJason Zaugg2014-02-102-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - fix typo - remove BRIDGE flag from the method that we promote from a bridge to a bona-fide method - note possibility for delambdafy to avoid the bridge method creation in *all* cases. - note inconsistency with anonymous class naming between `-Ydelamdafy:{inline,method}`
| * | | | | | SI-6260 Avoid double-def error with lambdas over value classesJason Zaugg2014-02-102-21/+27
| |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Post-erasure of value classs in method signatures to the underlying type wreaks havoc when the erased signature overlaps with the generic signature from an overriden method. There just isn't room for both. But we *really* need both; callers to the interface method will be passing boxed values that the bridge needs to unbox and pass to the specific method that accepts unboxed values. This most commonly turns up with value classes that erase to Object that are used as the parameter or the return type of an anonymous function. This was thought to have been intractable, unless we chose a different name for the unboxed, specific method in the subclass. But that sounds like a big task that would require call-site rewriting, ala specialization. But there is an important special case in which we don't need to rewrite call sites. If the class defining the method is anonymous, there is actually no need for the unboxed method; it will *only* ever be called via the generic method. I came to this realisation when looking at how Java 8 lambdas are handled. I was expecting bridge methods, but found none. The lambda body is placed directly in a method exactly matching the generic signature. This commit detects the clash between bridge and target, and recovers for anonymous classes by mangling the name of the target method's symbol. This is used as the bytecode name. The generic bridge forward to that, as before, with the requisite box/unbox operations.
* | | | | | Merge pull request #3406 from xeno-by/ticket/7570Jason Zaugg2014-02-102-11/+45
|\ \ \ \ \ \ | |_|_|_|/ / |/| | | | | SI-7570 top-level codegen for toolboxes
| * | | | | addresses pull request feedbackEugene Burmako2014-02-061-2/+1
| | | | | |
| * | | | | SI-7570 top-level codegen for toolboxesEugene Burmako2014-01-242-11/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provides a way to inject top-level classes, traits and modules into toolbox universes. Previously that was impossible, because compile and eval both wrap their arguments into an enclosing method of a synthetic module, which makes it impossible to later on refer to any definitions from the outside.
* | | | | | Merge pull request #3409 from xeno-by/ticket/6411Jason Zaugg2014-02-103-15/+8
|\ \ \ \ \ \ | |_|_|/ / / |/| | | | | SI-6411 SI-7328 value class fixes for runtime reflection
| * | | | | SI-6411 reflection is now aware of posterasureEugene Burmako2014-01-243-15/+8
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `transformedType` method, which is used to bring Scala types to Java world, was written in pre-valueclass times. Therefore, this method only called transforms from erasure, uncurry and refChecks. Now runtime reflection becomes aware of posterasure and as a consequence methods, which have value classes in their signatures, can be called without having to wrap them in catch-a-crash clause. Another facet to this fix was the realization that value classes need to be unwrapped, e.g. C(2) needs to be transformed to just 2, when they are used naked in method signatures (i.e. `c` in `def foo(c: C)` needs to be unwrapped, whereas `cs: List[C]`, `cs: C*` and even `cs: Array[C]` do not).
* | | | | Merge pull request #3433 from rjolly/si-7933Adriaan Moors2014-02-091-1/+12
|\ \ \ \ \ | | | | | | | | | | | | SI-7933 REPL javax.script eval is cached result
| * | | | | SI-7933 REPL javax.script eval is cached resultRaphael Jolly2014-01-311-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is that the repl underneath the script engine evaluates input to val res0..resN, so it is a one shot operation. To allow repetition, compile(script) now returns a CompiledScript object whose eval method can be called any number of times.
* | | | | | Merge pull request #3476 from retronym/ticket/8207Adriaan Moors2014-02-091-2/+8
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-8207 Allow import qualified by self reference
| * | | | | | SI-8207 Allow import qualified by self referenceJason Zaugg2014-02-061-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This regressed in SI-6815 / #2374. We check if the result of `typedQualifier(Ident(selfReference))` is a stable identifier pattern. But we actually see the expansion to `C.this`, which doesn't qualify. This commit adds a special cases to `importSig` to compensate. This is safe enough, because the syntax prevents the following: scala> class C { import C.this.toString } <console>:1: error: '.' expected but '}' found. class C { import C.this.toString } ^ So loosening the check here doesn't admit invalid programs. I've backed this up with a `neg` test. The enclosed test also checks that we can use the self reference in a singleton type, and as a qualifier in a type selection (These weren't actually broken.) Maybe it would be more principled to avoid expanding the self reference in `typedIdent`. I can imagine that the current situation is a pain for refactoring tools that try to implement a rename refactoring, for example. Seems a bit risky at the minute, but I've noted the idea in a comment.
* | | | | | | Merge pull request #3488 from retronym/ticket/8245Grzegorz Kossakowski2014-02-091-1/+3
|\ \ \ \ \ \ \ | |_|_|_|_|_|/ |/| | | | | | SI-8245 Fix regression in interplay between lazy val, return
| * | | | | | SI-8245 Fix regression in interplay between lazy val, returnJason Zaugg2014-02-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 4c86dbbc492 / SI-6358, synthesis of lazy val accessors trees was moved into the typer phase (in MethodSynthesis). Before that point, the symobl for the accessor *was* created early, but the tree was not. This led to crashes in intervening phases (extensionmethods) as `changeOwner` calls didn't catch the smuggled symbol. Moving the accessor generation forward, however, brought a problem: we now introduce a DefDef around the RHS of the lazy val, but we're not actually guaranteed that the body has already been typechecked. If it happened to be typechecked for the purposes of return type inference, we'll pick up the typechecked tree from `transformed`: // LazyValGetter#derivedTree val rhs1 = transformed.getOrElse(rhs0, rhs0) But if the method had an explicit return type (which must *always* be the case if it contains a `return`!), `rhs0` will be untyped. This leads to, e.g.: def foo(o: Option[Int]): Int = { lazy val i = o.getOrElse(return -1) i + 1 } def foo(o: Option[Int]): Int = { lazy <artifact> var i$lzy: Int = _; <stable> <accessor> lazy def i: Int = { i$lzy = o.getOrElse(return -1); i$lzy }; i.+(1) }; When this is typechecked, the `return` binds to the closest enclosing `DefDef`, `lazy def i`. This commit changes `Context#enclMethod` to treat `DefDef`s as transparent. `enclMethod` is only used in one other spot that enforces the implementation restriction that "module extending its companion class cannot use default constructor arguments".
* | | | | | | Merge pull request #3485 from xeno-by/topic/reset-all-attrsJason Zaugg2014-02-0911-71/+47
|\ \ \ \ \ \ \ | |_|_|_|_|/ / |/| | | | | | kills resetAllAttrs
| * | | | | | renames resetLocalAttrs to resetAttrsEugene Burmako2014-02-078-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now when resetAllAttrs is gone, we can use a shorter name for the one and only resetLocalAttrs.
| * | | | | | SI-8248 kills resetAllAttrsEugene Burmako2014-02-071-26/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Noone uses it anymore, so I'm rushing to remove it, so that it no longer can trick people into using it.
| * | | | | | does away with resetAllAttrs in typedLabelDefEugene Burmako2014-02-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Again, resetLocalAttrs works just fine there - no need to destroy references to externally defined symbols.
| * | | | | | does away with resetAllAttrs in the reifierEugene Burmako2014-02-071-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | resetLocalAttrs works just fine there
| * | | | | | further limits discoverability of resetAttrsEugene Burmako2014-02-077-22/+4
| |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit removes resetAllAttrs from the public reflection API. This method was previously deprecated, but on a second thought that doesn't do it justice. People should be aware that resetAllAttrs is just wrong, and if they have code that uses it, this code should be rewritten immediately without beating around the bush with deprecations. There's a source-compatible way of achieving that (resetLocalAttrs), so that shouldn't bring much trouble. Secondly, resetAllAttrs in compiler internals becomes deprecated. In subsequent commits I'm going to rewrite the only two locations in the compiler that uses it, and then I think we can remove it from the compiler as well.
* | | | | | Merge pull request #3420 from som-snytt/issue/8092-f-parsingEugene Burmako2014-02-093-174/+332
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-8092 More verify for f-interpolator
| * | | | | | SI-8092 Review cleanup, no qqSom Snytt2014-02-081-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No crazyquoting. Use global.abort on total fail. Remove unnecessary usage of varargs Apply, per review.
| * | | | | | SI-8092 Refactor f-interpSom Snytt2014-02-043-299/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A denshish refactor makes the FormatInterpolator a nice bundle that destructures its input and flattens out the classes to give the code some elbow room. Everything shifts left. The `checkType` method is refolded and renamed `pickAcceptable`. An additional test case captures the leading edge test, that a % should follow a hole, and which is the most basic requirement.
| * | | | | | SI-8092 More verify for f-interpolatorSom Snytt2014-01-281-137/+262
| | |_|_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Attempt to verify the nooks and crannies of the format string. Allows all syntax in the javadoc, including arg indexes. If the specifier after an arg has an index that doesn't refer to the arg, a warning is issued and the missing `%s` is prepended (just as for a part with a leading `%n`). Other enhancements include detecting that a `Formattable` wasn't supplied to `%#s`. Error messages attempt to be pithy but descriptive.
* | | | | | Add support for a more straightforward alternative to import selectorsDenys Shabalin2014-02-071-0/+2
| | | | | |
* | | | | | Represent tq"" as SyntacticEmptyTypeTree rather than TypeTree()Denys Shabalin2014-02-071-0/+2
| |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Such representation codifies the fact that type tree that doesn't have embedded syntactic equivalent must have been inferred or otherwise provided by the compiler rather than specified by the end user. Additionally it also ensures that we can still match trees without explicit types (e.g. vals without type) after typechecking. Otherwise the same quote couldn't be used in situations like: val q"val x = 42" = typecheck(q"val x = 42")
* | | | | Merge pull request #3475 from densh/topic/holemap-orderingEugene Burmako2014-02-062-20/+21
|\ \ \ \ \ | | | | | | | | | | | | Fix inconsistent binding in patterns with 10+ holes
| * | | | | Fix inconsistent binding in patterns with 10+ holesDenys Shabalin2014-02-062-21/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously a map that was storing bindings of fresh hole variables with their contents (tree & cardinality) used to be a SortedMap which had issues with inconsistent key ordering: "$fresh$prefix$1" < "$fresh$prefix$2" ... "$fresh$prefix$8" < "$fresh$prefix$9" "$fresh$prefix$9" > "$fresh$prefix$10" This issue is solved by using a LinkedHashMap instead (keys are inserted in the proper order.)
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-27 14:15:59 +0000