summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/typechecker/Namers.scala
Commit message (Collapse)AuthorAgeFilesLines
...
| * | SI-5954 Invalidate TypeRef cache when opening package objectJason Zaugg2014-01-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that the pos/5954d was tripping a println "assertion". This stemmed from an inconsistency between `TypeRef#{parents, baseTypeSeq}` for a package objects compiled from source that also has a class file from a previous compilation run. I've elevated the println to a devWarning, and changed `updatePosFlags`, the home of this evil symbol overwriting, to invalidate the caches in the symbols info. Yuck. I believe that this symptom is peculiar to package objects because of the way that the completer for packages calls `parents` during the Namer phase for package objects, before we switch the symbol to represent the package-object-from-source. But it seems prudent to defensively invalidate the caches for any symbol that finds its way into `updatePosFlags`.
| * | SI-8134 SI-5954 Fix companions in package object under separate comp.Jason Zaugg2014-01-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tests cases enclosed exhibited two failures modes under separate compilation. 1. When a synthetic companion object for a case- or implicit-class defined in a package object is called for, `Namer#ensureCompanionObject` is used to check for an explicitly defined companion before decided to create a synthetic one. This lookup of an existing companion symbol by `companionObjectOf` would locate a symbol backed by a class file which was in the scope of the enclosing package class. Furthermore, because the owner of that symbol is the package object class that has now been noted as corresponding to a source file in the current run, the class-file backed module symbol is *also* deemed to be from the current run. (This logic is in `Run#compiles`.) Thinking the companion module already existed, no synthetic module was created, which would lead to a crash in extension methods, which needs to add methods to it. 2. In cases when the code explicitly contains the companion pair, we still ran into problems in the backend whereby the class-file based and source-file based symbols for the module ended up in the same scope (of the package class). This tripped an assertion in `Symbol#companionModule`. We get into these problems because of the eager manner in which class-file based package object are opened in `openPackageModule`. The members of the module are copied into the scope of the enclosing package: scala> ScalaPackage.info.member(nme.List) res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462 scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List) res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462 This seems to require a two-pronged defense: 1. When we attach a pre-existing symbol for a package object symbol to the tree of its new source, unlink the "forwarder" symbols (its decls from the enclosing package class. 2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`, remove static member modules from the scope of the enclosing package object (aka `exitingFlatten(nestedModule.owner)`). This commit also removes the warnings about defining companions in package objects and converts those neg tests to pos (with -Xfatal-warnings to prove they are warning free.) Defining nested classes/objects in package objects still has a drawback: you can't shift a class from the package to the package object, or vice versa, in a binary compatible manner, because of the `package$` prefix on the flattened name of nested classes. For this reason, the `-Xlint` warning about this remains. This issue is tracked as SI-4344. However, if one heeds this warning and incrementatlly recompiles, we no longer need to run into a DoubleDefinition error (which was dressed up with a more specific diagnostic in SI-5760.) The neg test case for that bug has been converted to a pos.
* | | Merge pull request #3494 from retronym/topic/opt-any-ref-mapGrzegorz Kossakowski2014-02-101-1/+1
|\ \ \ | | | | | | | | Optimization: use AnyRef map for Namer -> Typer tree handoff
| * | | Optimization: use AnyRef map for Namer -> Typer tree handoffJason Zaugg2014-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #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.
* | | | | renames resetLocalAttrs to resetAttrsEugene Burmako2014-02-071-2/+2
| |/ / / |/| | | | | | | | | | | | | | | Now when resetAllAttrs is gone, we can use a shorter name for the one and only resetLocalAttrs.
* | | | Optimize use of methodTypeSchemaJason Zaugg2014-02-011-1/+2
|/ / / | | | | | | | | | | | | | | | | | | Cache it, rather than recreating it for each candidate overriden method we encounter. We can't do this eagerly as we trip a cycle in neg/t5093.scala.
* | | Merge pull request #3247 from soc/SI-8058-enumsAdriaan Moors2014-01-131-6/+23
|\ \ \ | |/ / |/| | SI-8058 Better support for enum trees
| * | SI-8058 Better support for enum treesSimon Ochsenreither2014-01-041-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the approach of “detect some magic combination of flags to trigger some action” by introducing an enum flag which makes the semantics and the intentions of the code using it more explicit. This basically involves wiring up the existing ACC_ENUM bit to a new modifier flag and making sure it is set correctly when encountering enums. The existing enum tests files/pos/t5165 and files/pos/t2764 keep working, showing that this hasn't introduced any obvious regressions. Tests for the changes in Namer which prevent scalac from messing with enum trees can't be added yet, because one currently can't define an enum in Scala without the help of the macro paradise. The intention is to add the @enum macro as a full test suite as soon as one can depend on macro annotations. One might wonder why we don't check for clazz.superClass == JavaEnumClass (where clazz is the owning class) in isEnumConstant. The reason is that this causes illegal cyclic reference error. Explanation by Eugene why this happens: (23:17:52) xeno_by: so here's what happens as far as I can understand at 11pm :) (23:18:09) xeno_by: scalac tries to complete the signature of the newly expanded class (23:18:11) xeno_by: to do that (23:18:40) xeno_by: to do that it needs three things (23:18:51) xeno_by: because the signature of a class is ClassInfoType which consists of three things (23:19:05) xeno_by: parents (23:19:08) xeno_by: decls (23:19:09) xeno_by: and symbol (23:19:20) xeno_by: symbol is easy - it's already there (23:19:30) xeno_by: parents are also easy (23:19:39) xeno_by: you just typecheck the things that come after "extends" (23:19:42) xeno_by: but decls are tricky (23:19:51) xeno_by: scalac goes through all the members of the class (23:20:03) xeno_by: and doesn't typecheck them... no, it doesn't (23:20:07) xeno_by: it just enters them (23:20:32) xeno_by: i.e. creates symbols for them and assigns lazy completers to those symbols so that if someone wants to know their signatures, they will go through the completers (23:20:34) xeno_by: and then (23:20:38) xeno_by: wait (23:20:40) xeno_by: there's one but (23:20:42) xeno_by: BUT (23:20:47) xeno_by: while we enter those symbols (23:20:53) xeno_by: our ClassInfoType is not ready yet (23:21:09) xeno_by: the class we're completing is still considered to be in the middle of being completing (23:21:12) xeno_by: so (23:21:24) xeno_by: when inside enterSym you try to ask that class for its super class (23:21:35) xeno_by: what happens is that check asks the class for its type signature (23:21:45) xeno_by: the ClassInfoType that consists of parents and decls (23:21:54) xeno_by: even though the parents are already calculated (23:22:01) xeno_by: the ClassInfoType as a whole is not (23:22:16) xeno_by: so scalac says that you're trying to complete something that's currently being completed (23:22:20) xeno_by: cyclic reference error (23:22:59) xeno_by: "cyclic" in English looks an awful lot like "суслик" in Russian (which means "gopher")
* | | Merge pull request #3235 from xeno-by/topic/macro-plugin-interfaceEugene Burmako2014-01-081-14/+26
|\ \ \ | | | | | | | | new hooks in AnalyzerPlugins to enable macro experimentation
| * | | hooks for naming and synthesis in Namers.scala and Typers.scalaEugene Burmako2013-12-301-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interestingly enough, despite of the implementation surface being quite noticeable, it is enough to hijack just `enterSym` and typechecking of stats for packages, templates and blocks in order to enable macro annotations. That and `ensureCompanionObject`, which I couldn't abstract away so far. An architectural note: given that a hooked method is called `X`, there are two implementations of this method. `pluginsX` is defined in AnalyzerPlugins.scala and lets macro plugins customize `X`. `standardX` is defined next to `X` and provides a default implementation. Finally `X` is changed to trivially forward to `pluginsX`. Existing and future callers of `X` now can be completely oblivious of the introduced hooks, because calls to `X` will continue working and will be correctly hooked. This makes the infrastructure more robust. The only downside is that in case when a macro plugin wants to call into the default implementation, it needs to call `standardX`, because `X` will lead to a stack overflow. However, in my opinion this not a big problem, because such failures are load and clear + for every `pluginsX` we actually provide documentation that says what is its standard impl is.
| * | | unprivates important helpers in Namers.scalaEugene Burmako2013-12-301-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first of two commits that enable hooks necessary to implement macro annotations in an honest, hackless compiler plugin. This particular commit turns certain helpers into public methods. Of course, there is a probability that with the evolution of macro paradise, I will need more helper methods, and those will have to be called via reflection, but at least for now it's nice to have a reflection-less plugin :)
| * | | manifests that Namers.mkTypeCompleter is flag-agnosticEugene Burmako2013-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When introducing `FlagAgnosticCompleter` and `FlagAssigningCompleter`, I have overlooked the completers created in namers. These completers only assign type signatures, not flags, because they are only created for symbols originating from sources and such symbols have their flags assigned based on modifiers and source def trees when they are entered.
| * | | gives a more specific signature to `computeMacroDefType`Eugene Burmako2013-12-301-3/+4
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I guess having `computeMacroDefType` is the remnant from the times when we considered an immediate possibility of having non-defdef macros, for instance type macros, which would be TypeDefs. These happy early days are gone, type macros have been long buried, and the perspectives of extensions to the existing def macro scheme are unclear. Therefore let’s have maximally precise types right away and then think of generalization later on, once/if we get there.
* / / awakens default getter synthesis from the untyper nightmareEugene Burmako2014-01-071-28/+54
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our happy little macro paradise is regularly invaded by resetAllAttrs, the bane of all macros and typers. It’s so ruthless and devastating that we’ve been long scheming to hack something really cool and to one day defeat it. Today we make the first step towards the happy future. Today we overthrow the UnTyper, resetAllAttrs’s elder brother that rules in the kingdoms of GetterLand and CaseClassia, and banish him from the land of getters. In the name of what’s good and meta, let’s band together and completely drive him away in a subsequent pull request! To put it in a nutshell, instead of using untyper on a DefDef to do default getter synthesis, the commit duplicates the DefDef and does resetLocalAttrs on it. As default getter synthesis proceeds with figuring out type and value parameters for the getter, then its tpt and finally its rhs, the commit destructures the duplicated DefDef and then assembles the default getter from the destructured parts instead of doing copyUntyped/copyUntypedInvariant on the original DefDef. I would say the test coverage is pretty good, as I had to figure out 3 or 4 test failures before I got to the stage when everything worked. Iirc it tests pretty exotic stuff like polymorphic default parameters in both second and third parameter lists, so it looks like we're pretty good in this department.
* | SI-8002 private access for local companionsJason Zaugg2013-11-241-0/+7
| | | | | | | | | | | | We go through similar gymnastics to make companion implicits work for local class/object pairings, so we ought to be consistent when it comes to access
* | Eliminate redundant pickling code.Paul Phillips2013-10-121-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit drops about 700 lines of redundant traversal logic. There had been ad hoc adjustments to the pickling scheme here and there, probably in pursuit of tiny performance improvements. For instance, a Block was pickled expr/stats instead of stats/expr, a TypeDef was pickled rhs/tparams instead of tparams/rhs. The benefits derived are invisible compared to the cost of having several hundred lines of tree traversal code duplicated in half a dozen or more places. After making Traverser consistent/complete, it was a straightforward matter to use it for pickling. It is ALSO now possible to write a vastly cleaner tree printer than the ones presently in trunk, but I leave this as an exercise for Dear Reviewer.
* | Removing unused code.Paul Phillips2013-10-021-7/+0
| | | | | | | | | | | | | | Most of this was revealed via -Xlint with a flag which assumes closed world. I can't see how to check the assumes-closed-world code in without it being an ordeal. I'll leave it in a branch in case anyone wants to finish the long slog to the merge.
* | Merge pull request #2987 from paulp/pr/emptySelfTypePaul Phillips2013-09-271-1/+1
|\ \ | | | | | | SI-6762 rename emptyValDef to emptySelfType.
| * | SI-6762 rename emptyValDef to noSelfType.Paul Phillips2013-09-271-1/+1
| | | | | | | | | | | | | | | Looks like emptyValDef.isEmpty was already changed to return false, so now all that's left is a name which means something.
* | | Fix up DEFAULTPARAM semantics.Paul Phillips2013-09-271-3/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I foolishly believed the deprecation message on "hasDefaultFlag" which suggested I use "hasDefault" instead. After lots of head scratching, I hardened the semantics so it's like this: - A method parameter with a default value is PARAM | DEFAULTPARAM - A default getter for such a parameter is METHOD | DEFAULTPARAM - And "hasDefault" is has(DEFAULTPARAM) && has(PARAM | METHOD) Why all the bonus logic, why not just hasFlag(DEFAULTPARAM)? For some reason we have a handful of overloaded flags spanning uses which someone apparently thinks can never intersect but I have not been so lucky overall. So since DEFAULTPARAM is overloaded with TRAIT, unless we think it's fine that default getters and method parameters with defaults will pose as traits all the time, there has to be an anchor bit alongside it.
* | Type housekeeping.Paul Phillips2013-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | Moved ListOfNil somewhere more generally accessible. No reason the compiler should hoard it for itself. Flitted to a few locations with constructs like ".head.head" and ".tail.head" looking for code which could be rewritten. Found some, admittedly not always making use of ListOfNil. Made overdue moves of ConstantType(Constant(true|false|null)) to vals in Definitions.
* | SI-7223 More finesse in setting INCONSTRUCTORJason Zaugg2013-09-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a clunky flag used to determine very early on whether we're in the self-call, super-call or early-init section. In SI-6666 / fd6125428, the check was improved to consider nesting. But, that caused this regression, as Function's haven't been translated to classes yet, so our check for enclosing non-term owners failed wrongly flagged definitins body of a anonymous function as INCONSTRUCTOR. With this patch, we correctly flag: class C extends D { // INCONSTRUCTOR () => { !INCONSTRUCTOR } // INCONSTRUCTOR }
* | Merge remote-tracking branch 'scala/2.10.x'Grzegorz Kossakowski2013-08-291-8/+0
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the merge, the test/run/t7733 started to fail on Jenkins. I tried to reproduce it locally but I couldn't so I think it's system dependent failure. Per @retronym's suggestion I moved it to pending to not block the whole merge. Conflicts: bincompat-backward.whitelist.conf bincompat-forward.whitelist.conf src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala src/compiler/scala/tools/nsc/typechecker/ContextErrors.scala src/compiler/scala/tools/nsc/typechecker/Macros.scala src/compiler/scala/tools/nsc/typechecker/Namers.scala src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala src/compiler/scala/tools/nsc/typechecker/RefChecks.scala src/compiler/scala/tools/nsc/util/MsilClassPath.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/reflect/scala/reflect/internal/ClassfileConstants.scala src/reflect/scala/reflect/internal/Importers.scala src/reflect/scala/reflect/internal/Trees.scala src/reflect/scala/reflect/runtime/JavaMirrors.scala test/files/run/macro-duplicate/Impls_Macros_1.scala test/files/run/t6392b.check test/files/run/t7331c.check
| * SI-7603 Remove diagnostic code for annotation errorJason Zaugg2013-08-161-8/+0
| | | | | | | | We've fingered the true culprit in the previous commit.
* | Logging cleanup.Paul Phillips2013-08-251-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Reduced the amount of extraneous logging noise at the default logging level. Was brought to my usual crashing halt by the discovery of identical logging statements throughout GenASM and elsewhere. I'm supposing the reason people so grossly underestimate the cost of such duplication is that most of the effects are in things which don't happen, aka "silent evidence". An example of a thing which isn't happening is the remainder of this commit, which exists only in parallel universes.
* | No longer crash on NoSymbol.owner.Paul Phillips2013-08-191-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically calling NoSymbol.owner has crashed the compiler. With this commit, NoSymbol owns itself. This is consistent with the way ownership chains are handled elsewhere in the compiler (e.g. NoContext.owner is NoContext, NoSymbol.enclClass is NoSymbol, and so on) and frees every call site which handles symbols from having to perform precondition tests against NoSymbol. Since calling NoSymbol.owner sometimes (not always) indicates a bug which we'd like to catch sooner than later, I have introduced a couple more methods for selected call sites. def owner: Symbol // NoSymbol.owner is self, log if -Xdev def safeOwner: Symbol // NoSymbol.owner is self, ignore def assertOwner: Symbol // NoSymbol.owner is fatal The idea is that everyone can call sym.owner without undue anxiety or paranoid null-like tests. When compiling under -Xdev calls to `owner` are logged with a stack trace, so any call sites for which that is an expected occurrence should call safeOwner instead to communicate the intention and stay out of the log. Conversely, any call site where crashing on the owner call was a desirable behavior can opt into calling assertOwner. This commit also includes all the safeOwner calls necessary to give us a silent log when compiling scala.
* | Merge pull request #2739 from retronym/ticket/7668Adriaan Moors2013-07-291-0/+3
|\ \ | | | | | | SI-7668 Better return type inheritance for dep. method types
| * | SI-7668 Better return type inheritance for dep. method typesJason Zaugg2013-07-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Return type inheritance already handles substitution of type parameters of the overriding method for those of the overriding. This commit extends this to do the same for parameter symbols.
* | | SI-7689 Fix typing regression with default argumentsJason Zaugg2013-07-241-1/+2
|/ / | | | | | | | | | | | | | | | | | | | | Regressed in e28c3edda4. That commit encoded upper/lower bounds of Any/Nothing as EmptyTree, which were triggering the .isEmpty check in Namers#TypeTreeSubstitutor and resulting in the default getter having TypeTree() as the return type. This resulted in a "missing parmameter type" error. This commit tightens up that condition to only consider empty TypeTrees (those wrapping null or NoType.)
* | Merge 2.10.x into masterAdriaan Moors2013-06-281-3/+12
|\| | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Namers.scala src/partest/scala/tools/partest/PartestTask.scala
| * SI-7603 Speculative fix for annotation binding errorJason Zaugg2013-06-241-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reports of: error: trait Test is abstract; cannot be instantiated 11:09:50 [ant:scalac] @Test def testClientRequestNum = { 11:09:50 [ant:scalac] ^ Suggest that the deferred processing of a LazyAnnotationInfo is binding the identifier `Test` to the wrong symbol. Inspection of the code shows that the closure also defers capture of the (mutable) field `Namer#typer.context`. This commit captures the context eagerly, and adds logging to let us know if that eagerly captured context ever differs from the its value at the point when the annotation info is forced. I spent a few hours trying to craft a test to back this up, but to no avail. Here's what the log output will look like: [log typer] The var `typer.context` in scala.tools.nsc.typechecker.Namers$NormalNamer@1f5ebb08 was mutated before the annotation new a() was forced. current value = Context(C@Import unit=<console> scope=123861466 errors=false, reportErrors=true, throwErrors=false) original value = Context(C@Import unit=<console> scope=123861466 errors=false, reportErrors=true, throwErrors=false) This confirms the hypothesis for the cause of SI-7603. If you see this message, please comment on that ticket.
| * SI-7232 Fix Java import vs defn. binding precendenceJason Zaugg2013-03-131-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Java Spec: > A single-type-import declaration d in a compilation unit c > of package p that imports a type named n shadows, throughout > c, the declarations of: > - any top level type named n declared in another compilation > unit of p > - any type named n imported by a type-import-on-demand > declaration in c > - any type named n imported by a static-import-on-demand > declaration in c Scala Spec: > Bindings of different kinds have a precedence defined on them: > 1. Definitions and declarations that are local, inherited, or made > available by a package clause in the same compilation unit where > the definition occurs have highest precedence. > 2. Explicit imports have next highest precedence.
* | SI-7264 Initialize owner when searching for companion.Jason Zaugg2013-06-051-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From ClassSymbol: protected final def companionModule0: Symbol = flatOwnerInfo.decl(name.toTermName).suchThat(sym => sym.isModuleNotMethod && (sym isCoDefinedWith this)) protected final def flatOwnerInfo: Type = { if (needsFlatClasses) info owner.rawInfo } Note the call to `rawInfo`; in the enclosed test case, that gives us back an uninitialized type for the module class of `Foo`, and consequently we don't find the companion for `Foo.Values`. This commit forces the initialization of the owning symbol if it was compiled in a prior run. In addition, it adds a special case to `Run#compiles` for early initialized symbols, which start out in life with the wrong owner. As best as I can see, that complexity stems from allowing early initialized members *without* return types to be used as value arguments to the super call, which in turn is needed to infer parent type arguments. The situation is described a little further in existing comments of `typedPrimaryConstrBody`. This bug is essentially another case of SI-6976. See the comments in pull request of that patch (https://github.com/scala/scala/pull/1910) for commit archaeology that shows why we're reluctant to force the owner info more broadly than is done in this commit.
* | Make all numeric coercions explicit.Paul Phillips2013-05-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Optimistically, this is preparation for a day when we don't let numeric types drift with the winds. Even without the optimism it's a good idea. It flushed out an undocumented change in the math package object relative to the methods being forwarded (a type is widened from what is returned in java) so I documented the intentionality of it. Managing type coercions manually is a bit tedious, no doubt, but it's not tedious enough to warrant abandoning type safety just because java did it.
* | Concision contribution.Paul Phillips2013-05-231-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have lots of core classes for which we need not go through the symbol to get the type: ObjectClass.tpe -> ObjectTpe AnyClass.tpe -> AnyTpe I updated everything to use the concise/direct version, and eliminated a bunch of noise where places were calling typeConstructor, erasedTypeRef, and other different-seeming methods only to always wind up with the same type they would have received from sym.tpe. There's only one Object type, before or after erasure, with or without type arguments. Calls to typeConstructor were especially damaging because (see previous commit) it had a tendency to cache a different type than the type one would find via other means. The two types would compare =:=, but possibly not == and definitely not eq. (I still don't understand what == is expected to do with types.)
* | SI-6815 untangle isStable and hasVolatileTypeAdriaan Moors2013-05-161-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `Symbol::isStable` is now independent of `Symbol::hasVolatileType`, so that we can allow stable identifiers that are volatile in ident patterns. This split is validated by SI-6815 and the old logic in RefChecks, which seems to assume this independence, and thus I don't think ever worked: ``` if (member.isStable && !otherTp.isVolatile) { if (memberTp.isVolatile) overrideError("has a volatile type; cannot override a member with non-volatile type") ``` Introduces `admitsTypeSelection` and `isStableIdentifierPattern` in treeInfo, and uses them instead of duplicating that logic all over the place. Since volatility only matters in the context of type application, `isStableIdentifierPattern` is used to check patterns (resulting in `==` checks) and imports.
* | Merge branch 'master' into pr/warning-cleanupPaul Phillips2013-04-241-3/+2
|\ \ | | | | | | | | | | | | Conflicts: src/compiler/scala/tools/nsc/typechecker/Contexts.scala
| * | SI-7345 Produce Context#imports from the context chainJason Zaugg2013-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than keeping a List[ImportInfo] around as a field. This sort of change reduces our bug exposure by structurally enforcing the invariant that `Context#imports` must mirror the `outer` chain. This entails changing a few elements of Contexts from mutable vars to constructor pararameters, which seems desirable anyway. We no longer need `makeNewImport`, as `make` now inspects the provided tree and determines does import specific things (tracking of used imports / mixin of ImportContext) when appropriate. The only wrinkle in this commit is the unfortunate need to pass `owner = null` in the extends clause of NoContext. I don't see cleaner way around this. Applied minor rework to `implicitss` to avoid needlessly re-evaluating `imports` and `nextOuter`.
| * | SI-7345 Rationalize overloads of Context#makeJason Zaugg2013-04-211-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Used default arguments and removed of variations only used in one place. I couldn't eliminate them all: one remaining overload avoids allocating a new context when the scope/owner/tree don't change, but moving this optimizatin to the primary overload of make breaks things. This is noted in a TODO comment.
* | | Eliminated the accumulated feature warnings.Paul Phillips2013-04-231-0/+1
|/ / | | | | | | | | | | | | | | | | No, this isn't busywork, how dare you suggest such a thing. I intend my tombstone to say HERE LIES EXTEMPORE, WHO ELIMINATED A LOT OF SIP-18 WARNINGS REST IN PEACE
* | Merge pull request #2327 from paulp/pr/2315-rebasedPaul Phillips2013-04-021-2/+2
|\ \ | | | | | | SI-7261 Implicit conversion of BooleanSetting to Boolean and BooleanFlag
| * | SI-7261 Implicit conversion of BooleanSetting to Boolean and BooleanFlagSom Snytt2013-03-271-2/+2
| | | | | | | | | | | | | | | | | | | | | This commit shortens expressions of the form `if (settings.debug.value)` to `if (settings.debug)` for various settings. Rarely, the setting is supplied as a method argument. The conversion is not employed in simple definitions where the Boolean type would have to be specified.
* | | Merge pull request #2317 from retronym/ticket/7232-masterAdriaan Moors2013-04-011-1/+7
|\ \ \ | | | | | | | | [forward-port] SI-7232 Fix Java import vs defn. binding precendence
| * | | SI-7232 Fix Java import vs defn. binding precendenceJason Zaugg2013-03-261-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Java Spec: > A single-type-import declaration d in a compilation unit c > of package p that imports a type named n shadows, throughout > c, the declarations of: > - any top level type named n declared in another compilation > unit of p > - any type named n imported by a type-import-on-demand > declaration in c > - any type named n imported by a static-import-on-demand > declaration in c Scala Spec: > Bindings of different kinds have a precedence defined on them: > 1. Definitions and declarations that are local, inherited, or made > available by a package clause in the same compilation unit where > the definition occurs have highest precedence. > 2. Explicit imports have next highest precedence. This is a forward port of 6e79370, which did not merge cleanly and was omitted in the regular merge from 2.10.x to master. Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
* | | | Merge pull request #2305 from retronym/ticket/7296-2Adriaan Moors2013-03-291-4/+3
|\ \ \ \ | |_|/ / |/| | | SI-7296 Lifting the limit on case class arity
| * | | SI-7296 Remove arity limit for case classesJason Zaugg2013-03-251-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When venturing above the pre-ordained limit of twenty two, `Companion extends FunctionN` and `Companion.unapply` are sacrificed. But oh-so-many other case class features work perfectly: equality/hashing/stringification, the apply method, and even pattern matching (which already bypasses unapply.) There was some understandable fear of the piecemeal when I tabled this idea on scala-internals [1]. But I'd like to persist as this limit is a needless source of pain for anyone using case classes to bind to database, XML or JSON schemata. [1] https://groups.google.com/forum/#!topic/scala-internals/RRu5bppi16Y
| * | | SI-7296 Avoid crash with nested 23-param case classJason Zaugg2013-03-251-1/+3
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | The implementation restriction doesn't stop subsequent typechecking in the same compilation unit from triggering type completion which tries to synthesize the unapply method. This commit predicates generation of the unapply method on having 22 or fewer parameters.
* / / Overhauled local/getter/setter name logic.Paul Phillips2013-03-251-3/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sifted through extraneous methods trying to find consistency, consolidating and deprecating as I went. The original motivation for all this was the restoration of LOCAL_SUFFIX to originalName, because: It looks like in an attempt to make originalName print consistently with decodedName, I went a little too far and stripped invisible trailing spaces from originalName. This meant outer fields would have an originalName of '$outer' instead of '$outer ', which in turn could have caused them to be mis-recognized as outer accessors, because the logic of outerSource hinges upon "originalName == nme.OUTER". I don't know if this affected anything - I noticed it by inspection, improbably enough. Deprecated originalName - original, compared to what? - in favor of unexpandedName, which has a more obvious complement. Introduced string_== for the many spots where people have given up and are comparing string representations of names. A light dusting of types is still better than nothing. Editoral note: LOCAL_SUFFIX is the worst. Significant trailing whitespace! It's a time bomb.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-20 21:44:36 +0000