summaryrefslogtreecommitdiff
path: root/src/compiler/scala/reflect/reify/codegen/GenSymbols.scala
Commit message (Collapse)AuthorAgeFilesLines
* Deprecations: Use of isPackage, hasSymbol, getter, setter...Simon Ochsenreither2015-03-261-1/+1
| | | | ... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
* Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-141-1/+1
|\
| * SI-8177 specializeSym must use memberInfo on high sideAdriaan Moors2014-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When determining whether member `symLo` of `tpLo` has a stronger type than member `symHi` of `tpHi`, should we use memberType or memberInfo? Well, memberType transforms (using `asSeenFrom`) `sym.tpe`, whereas memberInfo performs the same transform on `sym.info`. For term symbols, this ends up being the same thing (`sym.tpe == sym.info`). For type symbols, however, the `.info` of an abstract type member is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol, so that `sym.tpe <:< sym.info`, but not the other way around. Thus, for the strongest (correct) result, we should use `memberType` on the low side. On the high side, we should use the result appropriate for the right side of the `<:<` above (`memberInfo`). I also optimized the method a little bit by avoiding calling memberType if the symbol on the high side isn't eligble (e.g., it's a class). PS: I had to add a workaround to reifyType, because we now dealias a little less eagerly, which means a type selection on refinement class symbols makes it to reify this broke the t8104 tests. I also had to update the run/t6992 test, which should now test the right thing. Tests should be commented and/or use sensible names. What is it testing? What is the expected outcome? We should not be left guessing.
* | proceeds with the quest of removing `local` from namesEugene Burmako2014-02-121-2/+2
|/ | | | | Continuing in the direction set by the parent commit, this commit rephrases some more usages of `local` in names and comments in typer.
* merge flagsFromBits and FlagsAsBits into FlagsReprDen Shabalin2013-09-051-4/+4
|
* Doc -> C-style comments for local symbols to avoid "discardingEugene Vigdorchik2013-03-211-1/+1
| | | | | unmoored doc comment" warning when building distribution for scala itself.
* Merge remote-tracking branch 'origin/2.10.x' into merge-210Paul Phillips2013-02-101-0/+29
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * origin/2.10.x: Fix for paramaccessor alias regression. Expanded bytecode testing code. SI-5675 Discard duplicate feature warnings at a position accommodates pull request feedback term and type reftrees are now reified uniformly SI-6591 Reify and path-dependent types SI-7096 SubstSymMap copies trees before modifying their symbols SI-6961 no structural sharing in list serialization SI-6187 Make partial functions re-typable [backport] SI-6478 Fixing JavaTokenParser ident SI-7100 Fixed infinite recursion in duplicators SI-6146 More accurate prefixes for sealed subtypes. SI-5082 Cycle avoidance between case companions SI-6113 typeOf now works for type lambdas SI-5824 Fix crashes in reify with _* SI-7026: parseTree should never return a typed one SI-7070 Turn restriction on companions in pkg objs into warning Conflicts: src/compiler/scala/reflect/reify/codegen/GenSymbols.scala src/compiler/scala/tools/nsc/typechecker/PatternMatching.scala src/compiler/scala/tools/nsc/typechecker/Typers.scala src/compiler/scala/tools/reflect/ToolBoxFactory.scala src/library/scala/collection/immutable/List.scala src/reflect/scala/reflect/internal/TreeInfo.scala src/reflect/scala/reflect/internal/Types.scala src/reflect/scala/reflect/internal/settings/MutableSettings.scala src/reflect/scala/reflect/runtime/Settings.scala test/files/buildmanager/t2650_1/t2650_1.check test/files/buildmanager/t2657/t2657.check test/files/neg/t3234.check test/files/run/idempotency-this.check test/files/run/macro-typecheck-macrosdisabled2.check test/files/run/showraw_tree.check test/files/run/showraw_tree_ids.check test/files/run/showraw_tree_kinds.check test/files/run/showraw_tree_types_ids.check test/files/run/showraw_tree_types_typed.check test/files/run/showraw_tree_types_untyped.check test/files/run/showraw_tree_ultimate.check test/files/run/t2886.check test/files/run/t5225_2.check test/files/run/t5374.check test/files/run/t5374.scala test/files/run/t6329_repl.check test/files/run/toolbox_typecheck_macrosdisabled2.check
| * accommodates pull request feedbackEugene Burmako2013-02-081-2/+29
| | | | | | | | https://github.com/scala/scala/pull/2072
| * SI-6591 Reify and path-dependent typesDmitry Bushev2013-02-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reification scheme changed. Now Select an SelectFromTypeTree trees reified appropriately, as Select and SelectFromTypeTree accordingly. Packages and Predef object was excluded in order not to break the existing reification scheme and not to break tests which rely on it. Reified free terms can contain flag <stable> to make reified values become stable identifiers. For example in the case of reify_newimpl_15.scala class C { type T reify { val v: List[T] = List(2) } } class C reified as free term C$value, and List[C.T] becomes List[C$value().T], so C$value.apply() need to pass stability test isExprSafeToInline at scala.reflect.internal.TreeInfo. For this purpose special case for reified free terms was added to isExprSafeToInline function. test run/reify_newipl_30 disabled due to SI-7082 test t6591_4 moved to pending due to SI-7083
* | Remove TermName -> String implicit.Paul Phillips2012-12-021-3/+3
| | | | | | | | | | | | | | | | | | These implicits were crutches going back to a much Stringier time. Of course "with great type safety comes great verbosity" and no doubt this could be cleaned up significantly further. At least the underpinnings are consistent now - the only implicits involving name should be String -> TypeName and String -> TermName.
* | Remove Name -> TermName implicit.Paul Phillips2012-12-011-1/+1
| | | | | | | | And simplify the name implicits.
* | Removed unused imports.Paul Phillips2012-11-061-1/+0
|/ | | | | | | | | A dizzying number of unused imports, limited to files in src/compiler. I especially like that the unused import option (not quite ready for checkin itself) finds places where feature implicits have been imported which are no longer necessary, e.g. this commit includes half a dozen removals of "import scala.language.implicitConversions".
* SI-6372 cleans up the API of AttachmentsEugene Burmako2012-09-151-1/+1
| | | | | | | | | | | | Previously Attachments allowed multiple attachments that correspond to the same attachment type. This created a potential for confusion, given that Attachments.get only searched for the first attachment of a given type. Hence I made Attachments.add overwrite previously existing attachments of a given type and renamed it to Attachments.update, so that the name suits the intention better.
* SI-6323 outlaws free types from TypeTagEugene Burmako2012-09-141-0/+1
| | | | | | | | | | | | | | | | | Free types are no longer acceptable in normal type tags. Like type parameters or abstract type members they don't map on any real type, therefore I think this is a justified change. The main reason for doing is this is to prohibit people from using `typeOf` on local classes. Sure, the guard introduced in the previous commit will raise runtime errors about that, but this commit provides static checking. Those especially persistent might use `absTypeOf` and then try to play around with the weak type it returns, but that's advanced usage scenario, and I don't worry much about it. Bottom line: `typeOf` should just work. Things that work with additional effort should be explicitly marked as such.
* improvements for reification of free symbolsEugene Burmako2012-09-141-24/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Free symbols no longer carry signatures in their constructors. Previously to reify a free symbol (i.e. to generate a ValDef that creates it) one had to reify sym.info first. However reification of sym.info might lead to unexpected side effects, including stack overflows, if reification of sym.info recursively required reifying sym itself. Now it's not a problem. First we reify a "header" of a free symbol by emitting something like: val free$Foo1 = build.newFreeTerm("Foo", Foo.this, NoFlags)` Afterwards, when doing code generation for the reification symbol table, we populate free symbols by inserting calls to `build.setTypeSignature($sym.info)` This techniques transforms recursion into memoized iteration, because even if reifying sym.info indirectly requires reification of sym itself, we remember that we already reified sym and simply return things like Ident(free$Foo1). 2) Unfortunately I haven't been able to get rid of recursion completely. Since some symbols (e.g. local classes) aren't pickled, we need to recreate them during reification (this is necessary e.g. to reify RefinedTypes). Reifier uses a special function, named `reifySymDef`, for that purpose. Here's an example of how it works: val symdef$_1 = build.newNestedSymbol(free$U1, newTypeName("_"), NoPosition, DEFERRED | PARAM, false); `reifySymDef` expands into a call to `newNestedSymbol`, which requires an owner This essentially turns `reifySymDef` into a recursion of `reifySymDef` calls, so that the entire owner chain get reified. This is an implementation strategy that was employed in the first revision of the reifier written by Martin, and personally I have no clue whether it's really necessary to reify the parents. I leave this as a future work. 3) When working with free symbols, it's necessary to attach free symbols to their reification. This is required in obscure nested reification scenarios, when a symbol that was free for an inner reifee is no longer free for an outer reifee. In that case we need to remove that free symbol from the symbol table of the inner reification. Back then we didn't have tree attachments, so I had to introduce a phantom "value" parameter for `newFreeType` to keep track of the original symbols for free types. Now when we have attachments, this is no longer necessary and allowed me to clean up the code.
* removes build.newFreeExistentialEugene Burmako2012-09-141-2/+1
| | | | | | build.newFreeType does exactly the same, so we don't have a need in two different methods. Type parameters and existentially bound syms can later be distinguished using flags.
* cleanup of reflection- and macro-related stuffEugene Burmako2012-08-151-0/+1
| | | | | | mostly removes [Eugene] marks that I left back then and reviews related code some of those tokens got left in place, because I don't know to how fix them without imposing risks on 2.10.0
* SI-5756 correctly reifies local module classesEugene Burmako2012-08-091-1/+2
| | | | | | | | | | | | | | | | | | Unlike module classes that are going to be pickled (which are reified as `<their module reification>.moduleClass), module classes of local modules need to be reified as symbol defs. Otherwise we get a stack overflow: 1) Local modules are deemed to be free terms, 2) All free symbols are reified together with their type signature (so that they can be a) inspected by anyone interested, b) compiled at runtime), 3) Reifying a type signature of a module involves reifying its module class, 4) Reifying a module class involves reifying a module and calling its module class, <ad infinitum> This stack overflow doesn't happen for locatable modules, because they don't need to have their type signatures reified (these signatures can later be loaded from pickles if it becomes necessary).
* renames asType to toType and asXXXSymbol to asXXXEugene Burmako2012-08-021-1/+1
| | | | | | | This renaming arguably makes the intent of `asType` more clear, but more importantly it shaves 6 symbols off pervasive casts that are required to anything meaningful with reflection API (as in mirror.reflectMethod(tpe.member(newTermName("x")).asMethodSymbol)).
* SI-5999 a real fix to the packageless problemEugene Burmako2012-07-201-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a discussion on a reflection meeting on Jul 17 we concluded that we should split staticModule into staticModule and staticPackage to remove the ambiguity between packageless objects and packageless packages (more in the comments in the body of the commit). The motivation is verbosely outlined in the comments, but the bottom line is that Scala allows packages and packageless objects to have the same name within the same program. Therefore at times we need to disambiguate, hence the introduction of the staticPackage method. As of such staticModule no longer works for packages. In the same fashion staticPackage doesn't work for modules. This is done to ensure robustness of reification. I would like to do the same for getModule in Definitions, but we have to maintain backward compatibility. That's why I retained the old behavior, but replaced getModule invocations with getPackage where appropriate to be in line with staticModule and staticPackage. Another important thing that follows from the discussion is that both staticClass and staticModule prefer parent packages over parent objects in cases of ambiguity. Say, if we have the following snippet of code: object B { class C } next to package B { class C } then staticClass("B.C") will never even consider a C inside the object B. This is how scalac operates, so we decided to be consistent here. Finally reification logic got changed to distinguish between staticModule and staticPackage, and to allow for the fact that staticClass and staticModule prefer parent packages to parent objects.
* reify no longer dealiases symbols and typesEugene Burmako2012-07-021-4/+2
| | | | | this uncovers a bug in toolboxes: https://issues.scala-lang.org/browse/SI-6007 however that bug is not critical, so it will be dealt with later
* brings reification up to speedEugene Burmako2012-06-081-0/+109
Along with recovering from reflection refactoring, I implemented some new features (e.g. rollback of macro expansions), and did some stabilizing refactorings (e.g. moved mutable state into a ghetto). Also used the refactoring as a chance to fix free and aux symbols. Encapsulated this notion in a symbol table class, which allowed me to address outstanding issues with symbol table inheritance and inlining.