summaryrefslogtreecommitdiff
path: root/test/junit/scala/tools/nsc/symtab
Commit message (Collapse)AuthorAgeFilesLines
* SI-10093 don't move member traits to constructor body in constructorsLukas Rytz2016-12-061-2/+38
| | | | | | | | | | | | | | | | Fixes a regression introduced in c8e6050. Member traits with only abstract definitions (`isInterface`) were moved into the primary constructor by mistake. (Flatten moved the classes back.) The member trait was duplicated into the constructor of specialized subclasses, causing it to be generated multiple times. Also removes some unnecessary `isMixinConstructor` checks: the mixin constructor is always the primary constructor. This commit also clarifies (and tests) what `isInterface` means: for scala-defined traits, it means there are only abstract members. For java-defined interfaces, it is always true.
* re-enable two tests (starr is up to date now)Lukas Rytz2016-09-301-3/+4
|
* Reduce flag fiddlingAdriaan Moors2016-08-111-5/+0
| | | | | | | | | | | | | | | There isn't much point to the late* flags in a world where we're mutating flags left and right in tree and info transformers... So, lets get rid of the indirection until we can include flags in a symbol's type history, like we do for its info. This retires lateDEFERRED (redundant with SYNTHESIZE_IMPL_IN_SUBCLASS). Since it's introduced so late, it makes little sense to have these synthetic members go back to DEFERRED. Instead, just set DEFERRED directly. Also remove unused late* and not* flags. notPRIVATE subsumes lateFINAL for effective finality (scala/scala-dev#126)
* Add since arg to deprecationWarning and use itSimon Ochsenreither2016-05-291-1/+1
|
* Remove abstraction layer in classpath implementationLukas Rytz2016-05-021-8/+5
|
* remove recursive classpath implementationLukas Rytz2016-04-231-17/+3
|
* Support :require when using the flat classpath representation.Lukas Rytz2016-03-221-3/+3
| | | | | | :require was re-incarnated in https://github.com/scala/scala/pull/4051, it seems to be used by the spark repl. This commit makes it work when using the flat classpath representation.
* New trait encoding: use default methods, jettison impl classesJason Zaugg2016-03-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, concrete methods in traits were encoded with "trait implementation classes". - Such a trait would compile to two class files - the trait interface, a Java interface, and - the implementation class, containing "trait implementation methods" - trait implementation methods are static methods has an explicit self parameter. - some methods don't require addition of an interface method, such as private methods. Calls to these directly call the implementation method - classes that mixin a trait install "trait forwarders", which implement the abstract method in the interface by forwarding to the trait implementation method. The new encoding: - no longer emits trait implementation classes or trait implementation methods. - instead, concrete methods are simply retained in the interface, as JVM 8 default interface methods (the JVM spec changes in [JSR-335](http://download.oracle.com/otndocs/jcp/lambda-0_9_3-fr-eval-spec/index.html) pave the way) - use `invokespecial` to call private or particular super implementations of a method (rather `invokestatic`) - in cases when we `invokespecial` to a method in an indirect ancestor, we add that ancestor redundantly as a direct parent. We are investigating alternatives approaches here. - we still emit trait fowrarders, although we are [investigating](https://github.com/scala/scala-dev/issues/98) ways to only do this when the JVM would be unable to resolve the correct method using its rules for default method resolution. Here's an example: ``` trait T { println("T") def m1 = m2 private def m2 = "m2" } trait U extends T { println("T") override def m1 = super[T].m1 } class C extends U { println("C") def test = m1 } ``` The old and new encodings are displayed and diffed here: https://gist.github.com/retronym/f174d23f859f0e053580 Some notes in the implementation: - No need to filter members from class decls at all in AddInterfaces (although we do have to trigger side effecting info transformers) - We can now emit an EnclosingMethod attribute for classes nested in private trait methods - Created a factory method for an AST shape that is used in a number of places to symbolically bind to a particular super method without needed to specify the qualifier of the `Super` tree (which is too limiting, as it only allows you to refer to direct parents.) - I also found a similar tree shape created in Delambdafy, that is better expressed with an existing tree creation factory method, mkSuperInit.
* SI-9473 Cleaner references to statically owned symbolsJason Zaugg2015-09-221-1/+3
| | | | | | | | | | | | Ever wonder why `identity("")` typechecks to `scala.this.Predef.identity("")`? It turns out that `mkAttributedRef` was importing `q"$scalaPackageClass.this.Predef._"` for all these years, rather than `q"$scalaModule.Predef._"`. This commit makes `mkAttributedRef` special case static owners by referring the the corresponding module, instead.
* Query methods in api.Symbols for Java flagsLukas Rytz2015-07-221-0/+7
| | | | | | | | | | | | | | | | | | | Adds query methods to the public reflection API for querying the JAVA_ENUM and JAVA_ANNOTATION flags. Didn't include JAVA_DEFAULTMETHOD because it does not correspond to a real java classfile flag (just a non-abstract method in an interface), and we want to clean the usage of this flag before adding it to a public API. The flags themselfs are not added to the reflection API. A comment in api/FlagSets.scala says: Q: I have a pretty flag. Can I put it here? A: Only if there's a tree that cannot be built without it. If you want to put a flag here so that it can be tested against, introduce an `isXXX` method in one of the api.Symbols classes instead.
* SI-9393 fix modifiers of ClassBTypes for Java annotationsLukas Rytz2015-07-221-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scala classfile and java source parsers make Java annotation classes (which are actually interfaces at the classfile level) look like Scala annotation classes: - the INTERFACE / ABSTRACT flags are not added - scala.annotation.Annotation is added as superclass - scala.annotation.ClassfileAnnotation is added as interface This makes type-checking @Annot uniform, whether it is defined in Java or Scala. This is a hack that leads to various bugs (SI-9393, SI-9400). Instead the type-checking should be special-cased for Java annotations. This commit fixes SI-9393 and a part of SI-9400, but it's still easy to generate invalid classfiles. Restores the assertions that were disabled in #4621. I'd like to leave these assertions in: they are valuable and helped uncovering the issue being fixed here. A new flag JAVA_ANNOTATION is introduced for Java annotation ClassSymbols, similar to the existing ENUM flag. When building ClassBTypes for Java annotations, the flags, superclass and interfaces are recovered to represent the situation in the classfile. Cleans up and documents the flags space in the area of "late" and "anti" flags. The test for SI-9393 is extended to test both the classfile and the java source parser.
* new{Term,Type}Name→{Term,Type}Name, tpename/nme→{type,term}NamesSimon Ochsenreither2015-03-261-2/+2
|
* SI-8818 FreshName extractor forgives suffixSom Snytt2015-02-091-6/+6
| | | | | | The test is corrected (inverted) and the extractor is made more succinct. Succinctness isn't enforced by the test, but I checked it manually.
* SI-9133 Harden against infinite loop in NoSymbol.ownerJason Zaugg2015-02-031-0/+5
| | | | | | | | | | | | | | | The available evidence gathered in an IDE hang suggests that while editing erronenous code, a call to `Erasure#javaSig` by the IDE's structure builder triggered the `ExplicitOuter` info transformer on a symbol with some sort of incoherent owner chain, which led to an infinite loop in `NoSymbol#outerClass`. This commit hardens that method to work in the same manner as a call to `NoSymbol.owner`: log the error under -Xdev or -Ydebug and return return `NoSymbol` to soldier on without crashing / hanging. I haven't formulated a theory about how we might have ended up with the corrupt owner chain.
* Fix many typos in docs and commentsmpociecha2014-12-141-1/+1
| | | | | | | | | | | | | This commit corrects many typos found in scaladocs, comments and documentation. It should reduce a bit number of PRs which fix one typo. There are no changes in the 'real' code except one corrected name of a JUnit test method and some error messages in exceptions. In the case of typos in other method or field names etc., I just skipped them. Obviously this commit doesn't fix all existing typos. I just generated in IntelliJ the list of potential typos and looked through it quickly.
* Cleanup and refactoring - semicolons, unused or commented out codempociecha2014-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit contains some minor changes made by the way when implementing flat classpath. Sample JUnit test that shows that all pieces of JUnit infrastructure work correctly now uses assert method form JUnit as it should do from the beginning. I removed commented out lines which were obvious to me. In the case of less obvious commented out lines I added TODOs as someone should look at such places some day and clean them up. I removed also some unnecessary semicolons and unused imports. Many string concatenations using + have been changed to string interpolation. There's removed unused, private walkIterator method from ZipArchive. It seems that it was unused since this commit: https://github.com/scala/scala/commit/9d4994b96c77d914687433586eb6d1f9e49c520f However, I had to add an exception for the compatibility checker because it was complaining about this change. I made some trivial corrections/optimisations like use 'findClassFile' method instead of 'findClass' in combination with 'binary' to find the class file.
* Integrate flat classpath with the compilermpociecha2014-12-051-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit integrates with the compiler the whole flat classpath representation build next to the recursive one as an alternative. From now flat classpath really works and can be turned on. There's added flag -YclasspathImpl with two options: recursive (the default one) and flat. It was needed to make the dynamic dispatch to the particular classpath representation according to the chosen type of a classpath representation. There's added PathResolverFactory which is used instead of a concrete implementation of a path resolver. It turned out that only a small subset of path resolvers methods is used outside this class in Scala sources. Therefore, PathResolverFactory returns an instance of a base interface PathResolverResult providing only these used methods. PathResolverFactory in combination with matches in some other places ensures that in all places using classpath we create/get the proper representation. Also the classPath method in Global is modified to use the dynamic dispatch. This is very important change as a return type changed to the base ClassFileLookup providing subset of old ClassPath public methods. It can be problematic if someone was using in his project the explicit ClassPath type or public methods which are not provided via ClassFileLookup. I tested flat classpath with sbt and Scala IDE and there were no problems. Also was looking at sources of some other projects like e.g. Scala plugin for IntelliJ and there shouldn't be problems, I think, but it would be better to check these changes using the community build. Scalap's Main.scala is changed to be able to use both implementations and also to use flags related to the classpath implementation. The classpath invalidation is modified to work properly with the old (recursive) classpath representation after changes made in a Global. In the case of the attempt to use the invalidation for the flat cp it just throws exception with a message that the flat one currently doesn't support the invalidation. And also that's why the partest's test for the invalidation has been changed to use (always) the old implementation. There's added an adequate comment with TODO to this file. There's added partest test generating various dependencies (directories, zips and jars with sources and class files) and testing whether the compilation and further running an application works correctly, when there are these various types of entries specified as -classpath and -sourcepath. It should be a good approximation of real use cases.
* SI-8947 Avoid cross talk between tag materializers and reifyJason Zaugg2014-10-301-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a macro has been expanded, the expandee are expansion are bidirectionally linked with tree attachments. Reify uses the back reference to replace the expansion with the expandee in the reified tree. It also has some special cases to replace calls to macros defined in scala-compiler.jar with `Predef.implicitly[XxxTag[T]]`. This logic lives in `Reshape`. However, the expansion of a macro may be `EmptyTree`. This is the case when a tag materializer macro fails. User defined macros could do the also expand to `EmptyTree`. In the enclosed test case, the error message that the tag materializer issued ("cannot materialize class tag for unsplicable type") is not displayed as the typechecker finds another means of making the surrounding expression typecheck. However, the macro engine attaches a backreference to the materializer macro on `EmpytyTree`! Later, when `reify` reshapes a tree, every occurance of `EmptyTree` will be replaced by a call to `implicitly`. This commit expands the domain of `CannotHaveAttrs`, which is mixed in to `EmptyTree`. It silently ignores all attempts to mutate attachments. Unlike similar code that discards mutations of its type and position, I have refrained from issuing a developer warning in this case, as to silence this I would need to go and add a special case at any places adding attachments.
* Get rid of Platform.doLoad method.Grzegorz Kossakowski2014-09-241-1/+0
| | | | Since .NET backend got removed this method is a no-op.
* Fix assertThrows, and the behaviors that it shadowedLukas Rytz2014-09-023-6/+10
| | | | | | The test in StdNamesTest was introduced in cff8b569, where newTermName would throw on a negative length. In b090f97 this was changed to fix the negative length, but the test was not adapted (as it didn't fail).
* Remove deprecationWarning, currentReporting from ReportingAdriaan Moors2014-07-041-0/+7
| | | | | | | | This moves us a bit closer to the goal of having a single entry point to reporting. Must modularize Reporting a bit so it can be used in Variances (need a reference to `currentRun` in `reflect.internal.Reporting`).
* Uniformly route reporting through reporter.Adriaan Moors2014-07-041-0/+5
| | | | | | | | | | | | Sharpen interfaces, reduce footprint of Reporting trait. Ideally, all reporting should indirect through reporter, and the `Reporting` trait itself should be restricted to a single method that retrieves the current `reporter`. Pull up some more reporting to reflect.internal. Would like to do more, but need to move partest to the reflect.internal interface first. (Its `errorCount` relies on `ERROR.count` in `tools.nsc.Reporter`.)
* additional class tags for reflection APIEugene Burmako2014-02-141-0/+6
| | | | | | | | | 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.
* SI-6411 reflection is now aware of posterasureEugene Burmako2014-01-241-0/+1
| | | | | | | | | | | | | | | | 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).
* refactor out fresh name prefix extraction logicDen Shabalin2013-11-171-0/+47
| | | | | | | | | | | 1. refactor out FreshNameExtractor out of Quasiquotes cake into SymbolTable (can’t put it outside due to the fact that names are path-dependent) 2. add optional parameter to the fresh name creator to cover additional qq$ prefix needed for quasiquotes 3. add unit tests
* re-wire fresh name creator to currentUnit.fresh at compile-timeDen Shabalin2013-10-181-0/+2
|
* Rework cff8b569 to heal the windows build.Jason Zaugg2013-10-031-4/+4
| | | | | | | | | - change newTermName to fix negative length names rather than reject them - restore the old logic in unspecializedName for names that result from AnyRef specialized type parameters. Why does fix the windows build? I remain none the wiser.
* SI-7841 More robust unspecialization of namesJason Zaugg2013-09-161-0/+46
| | | | | | | | | | | | | | | | | | | | Names like `T1$sp`, which can arise from `AnyRef` specialization, were leading to negative length Names if they ever passed through `unspecializedName` or `splitSpecializedName`. This code path was touched when printing the tree of a certain AnyRef specialized classes after specialization, such as `AbstractPartialFunction` (which had such specialization until a few commits ago.) This commit handles that case correctly, and generally hardens against unexpected names, which could pop up from third party classes. The documentation for `splitSpecializedName` transposed the class and method specializations. The things you discover when you turn examples in documentation in to test cases! In addition, we now require non-negative length and offset in `newTermName`
* addresses feedback regarding new junit testsDen Shabalin2013-08-152-14/+8
| | | | | | | | | 1. don't recreate symbol table manually and just let JUnit do it automatically behind the scenes 2. minor changes to assertThrow's description 3. add one more test case to check that exception's subclasses are catched too 4. refine rethrow test to ensure that the exception wasn't swallowed
* SI-7731 make CannotHaveAttrs more consistentDen Shabalin2013-08-141-0/+70
| | | | | | | | | | | Previously setPos, pos_=, setType, tpe_= all behaved inconsistently between each other even though they all represent similar attributes that cannot be changed on CannotHaveAttrs trees. In order to simplify handling of such trees in compiler code each of these fields now supports assignment to its current default value: NoType for tpe and NoPosition for pos. Such assignments don't mutate underlying trees.
* Add sample to SymbolTableTest using custom symbols and type.Grzegorz Kossakowski2013-08-021-0/+21
| | | | | Add a test which demonstrates how one can create symbols and types from scratch and perform sub type check using them.
* Address TODOs around SymbolLoaders and SymbolTable.Grzegorz Kossakowski2013-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | SymbolTable refactoring introduced some TODOs that were supposed to be addressed after M5 release. The reason I couldn't address those problems right away was a conflict with our plans to modularize Scaladoc and interactive. However, we decided to delay that work until after M5 is released so addressing TODOs is not blocked anymore. This commit introduces the following changes: * Eclipse project definitions for interactive and scaladoc depend on scala-compiler project so they are builded against latest version of the compiler (quick) instead of STARR. This aligns our Eclipse project definitions with build.xml structure. * Introduce GlobalSymbolLoaders class which wires dependencies of SymbolLoaders with assumption of dependency on Global. * Switch to GlobalSymbolLoaders in BrowsingLoaders, interactive Global and ScaladocGlobal; this eliminates all TODO comments introduced before
* Add example of SymbolTable unit test.Grzegorz Kossakowski2013-07-272-0/+118
Add a SymbolTableTest which contains all the code needed to initialize a SymbolTable in JUnit environment. It shows that initialization of definitions works and one can easily lookup some symbols and perform tests like subtyping tests.