summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/symtab/classfile
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #5724 from jvican/stub-errors-2.12.xAdriaan Moors2017-03-271-3/+10
|\ | | | | SCP-009: Improve direct dependency experience
| * Improve stub error messages (SCP-009 proposal)jvican2017-03-241-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit message is a squash of several commit messages. - This is the 1st commit message: Add position to stub error messages Stub errors happen when we've started the initialization of a symbol but key information of this symbol is missing (the information cannot be found in any entry of the classpath not sources). When this error happens, we better have a good error message with a position to the place where the stub error came from. This commit goes into this direction by adding a `pos` value to `StubSymbol` and filling it in in all the use sites (especifically `UnPickler`). This commit also changes some tests that test stub errors-related issues. Concretely, `t6440` is using special Partest infrastructure and doens't pretty print the position, while `t5148` which uses the conventional infrastructure does. Hence the difference in the changes for both tests. - This is the commit message #2: Add partest infrastructure to test stub errors `StubErrorMessageTest` is the friend I introduce in this commit to help state stub errors. The strategy to test them is easy and builds upon previous concepts: we reuse `StoreReporterDirectTest` and add some methods that will compile the code and simulate a missing classpath entry by removing the class files from the class directory (the folder where Scalac compiles to). This first iteration allow us to programmatically check that stub errors are emitted under certain conditions. - This is the commit message #3: Improve contents of stub error message This commit does three things: * Keep track of completing symbol while unpickling First, it removes the previous `symbolOnCompletion` definition to be more restrictive/clear and use only positions, since only positions are used to report the error (the rest of the information comes from the context of the `UnPickler`). Second, it adds a new variable called `lazyCompletingSymbol` that is responsible for keeping a reference to the symbol that produces the stub error. This symbol will usually (always?) come from the classpath entries and therefore we don't have its position (that's why we keep track of `symbolOnCompletion` as well). This is the one that we have to explicitly use in the stub error message, the culprit so to speak. Aside from these two changes, this commit modifies the existing tests that are affected by the change in the error message, which is more precise now, and adds new tests for stub errors that happen in complex inner cases and in return type of `MethodType`. * Check that order of initialization is correct With the changes introduced previously to keep track of position of symbols coming from source files, we may ask ourselves: is this going to work always? What happens if two symbols the initialization of two symbols is intermingled and the stub error message gets the wrong position? This commit adds a test case and modifications to the test infrastructure to double check empirically that this does not happen. Usually, this interaction in symbol initialization won't happen because the `UnPickler` will lazily load all the buckets necessary for a symbol to be truly initialized, with the pertinent addresses from which this information has to be deserialized. This ensures that this operation is atomic and no other symbol initialization can happen in the meantime. Even though the previous paragraph is the feeling I got from reading the sources, this commit creates a test to double-check it. My attempt to be better safe than sorry. * Improve contents of the stub error message This commit modifies the format of the previous stub error message by being more precise in its formulation. It follows the structured format: ``` s"""|Symbol '${name.nameKind} ${owner.fullName}.$name' is missing from the classpath. |This symbol is required by '${lazyCompletingSymbol.kindString} ${lazyCompletingSymbol.fullName}'. ``` This format has the advantage that is more readable and explicit on what's happening. First, we report what is missing. Then, why it was required. Hopefully, people working on direct dependencies will find the new message friendlier. Having a good test suite to check the previously added code is important. This commit checks that stub errors happen in presence of well-known and widely used Scala features. These include: * Higher kinded types. * Type definitions. * Inheritance and subclasses. * Typeclasses and implicits. - This is the commit message #4: Use `lastTreeToTyper` to get better positions The previous strategy to get the last user-defined position for knowing what was the root cause (the trigger) of stub errors relied on instrumenting `def info`. This instrumentation, while easy to implement, is inefficient since we register the positions for symbols that are already completed. However, we cannot do it only for uncompleted symbols (!hasCompleteInfo) because the positions won't be correct anymore -- definitions using stub symbols (val b = new B) are for the compiler completed, but their use throws stub errors. This means that if we initialize symbols between a definition and its use, we'll use their positions instead of the position of `b`. To work around this we use `lastTreeToTyper`. We assume that stub errors will be thrown by Typer at soonest. The benefit of this approach is better error messages. The positions used in them are now as concrete as possible since they point to the exact tree that **uses** a symbol, instead of the one that **defines** it. Have a look at `StubErrorComplexInnerClass` for an example. This commit removes the previous infrastructure and replaces it by the new one. It also removes the fields positions from the subclasses of `StubSymbol`s. - This is the commit message #5: Keep track of completing symbols Make sure that cycles don't happen by keeping track of all the symbols that are being completed by `completeInternal`. Stub errors only need the last completing symbols, but the whole stack of symbols may be useful to reporting other error like cyclic initialization issues. I've added this per Jason's suggestion. I've implemented with a list because `remove` in an array buffer is linear. Array was not an option because I would need to resize it myself. I think that even though list is not as efficient memory-wise, it probably doesn't matter since the stack will usually be small. - This is the commit message #6: Remove `isPackage` from `newStubSymbol` Remove `isPackage` since in 2.12.x its value is not used.
* | SI-10231 Skip outer parameter when classfile parsing java param namesLukas Rytz2017-03-171-7/+17
|/ | | | | | | Nested java classes have a synthetic outer parameter, which the classfile parser skips for the constructor symbol. When assigning parameter names from the MethodParameters classfile attribute, we also need to skip the first name in this case.
* Merge commit '36967321c7' into merge-2.11.x-to-2.12.x-20170214Seth Tisue2017-02-161-3/+2
|\
| * SI-9331 Fix canEqual for case classes with HK type paramsJason Zaugg2017-01-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Time for the courage of our convictions: follow the advice of my TODO comment from SI-8244 / f62e280825 and fix `classExistentialType` once and for all. This is the change in the generated `canEquals` method in the test case; we no longer get a kind conformance error. ``` --- sandbox/old.log 2015-05-27 14:31:27.000000000 +1000 +++ sandbox/new.log 2015-05-27 14:31:29.000000000 +1000 @@ -15,7 +15,7 @@ case _ => throw new IndexOutOfBoundsException(x$1.toString()) }; override <synthetic> def productIterator: Iterator[Any] = runtime.this.ScalaRunTime.typedProductIterator[Any](Stuff.this); - <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[Proxy[PP]]](); + <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[_ <: [PP]Proxy[PP]]](); override <synthetic> def hashCode(): Int = ScalaRunTime.this._hashCode(Stuff.this); override <synthetic> def toString(): String = ScalaRunTime.this._toString(Stuff.this); override <synthetic> def equals(x$1: Any): Boolean = x$1 match { @@ -38,9 +38,3 @@ } } ``` I also heeded my own advice to pass in a prefix to this method.
| * [nomerge] SI-10037 ASR/LSR switched in ICodeReaderSom Snytt2016-11-101-4/+4
| | | | | | | | | | | | | | | | | | | | Noticed when inlining from a class file. The test doesn't work because inlining fails with bytecode unavailable due to: ``` scala.reflect.internal.MissingRequirementError: object X in compiler mirror not found. ```
* | Merge pull request #5384 from som-snytt/issue/9915Seth Tisue2016-11-141-2/+6
|\ \ | | | | | | SI-9915 Utf8_info are modified UTF8
| * | SI-9915 Utf8_info are modified UTF8Som Snytt2016-10-201-2/+6
| | | | | | | | | | | | | | | | | | Use DataInputStream.readUTF to read CONSTANT_Utf8_info. This fixes reading embedded null char and supplementary chars.
* | | Address review commentsLukas Rytz2016-10-281-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | Tighten some types (Symbol -> ClassSymbol / ModuleSymbol), use NonFatal instead of catching Throwable. Also don't run the classfile parser enteringPhase(phaseBeforeRefchecks) anymore. This was added in 0ccdb15 but seems no longer required.
* | | For scala classfiles, only parse the scala signature annotationLukas Rytz2016-10-281-24/+45
| | | | | | | | | | | | | | | | | | Skipping other annotations not only saves some cycles / GC, but also prevents some spurious warnings / errors related to cyclic dependencies when parsing annotation arguments refering to members of the class.
* | | Minor style cleanups, no changes in logicLukas Rytz2016-10-271-4/+4
| | |
* | | Classfile parser and unpickler require class and module symbol argumentsLukas Rytz2016-10-271-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In SymbolLoaders, when seeing a classfile `Foo.class`, we always (unconditionally) create 3 symbols: a class, a module and a module class. Some symbols get invalidated later (`.exists`). Until now, the classfile parser (and unpickler) received the "root" symbol as argument, which is the symbol whose type is being completed. This is either the class symbol or the module symbol. The classfile parser would then try to lookup the other symbol through `root.companionClass` or `root.companionModule`. Howver, this lookup can fail. One example is scala-dev#248: when a type alias (in a package object) shadows a class symbol, `companionClass` will fail. The implementations of the classfile parser / unpickler assume that both the `clazz` and the `staticModule` symbols are available. This change makes sure that they are always passed in explicitly. Before this patch, in the example of scala-dev#248, the `classRoot` of the unpickler was NoSymbol. This caused a bug when unpickling the module class symbol, causing a second module class symbol to be created mistakingly. The next commit cleans up this logic, more details there. This second symbol would then cause the crash in the backend because it doesn't have an `associatedFile`, therefore `isCoDefinedWith` would spuriously return `true`.
* | | Clean up cross-check in classfile parser, remove unnecessary assignmentLukas Rytz2016-10-271-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the first entries in the classfile is the class name. The classfile parser performs a cross-check by looking up the class sybmol corresponding to that name and ensures it's the same as `clazz`, the class symbol that the parser currently populates. Since 322c980 ("Another massive IDE checkin"), if at the time of the check `clazz` but the lookup returns some class, the `clazz` field is assigned. The commit following this one makes sure `clazz` is never NoSymbol, so the assignment can safely be removed.
* | | Clean up lookup class by name in the classfile parserLukas Rytz2016-10-271-46/+26
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a piece of logic essentially duplicating getClassByName in Mirrors (split up a fully qualified class name by ".", look up pieces). That piece of code was added in 0ce0ad5 to fix one example in SI-2464. However, since 020053c (2012, 2.10) that code was broken: the line ss = name.subName(0, start) should be ss = name.subName(start, name.length).toTypeName As a result, the code would always create a stub symbol. Returning a stub seems to be the right thing to do anyway, and the fact that we were doing so during two major releases is a good proof.
* | Disable stub warning by default.Oscar Boykin2016-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we create a class symbols from a classpath elements, references to other classes that are absent from the classpath are represented as references to "stub symbols". This is not a fatal error; for instance if these references are from the signature of a method that isn't called from the program being compiled, we don't need to know anything about them. A subsequent attempt to look at the type of a stub symbols will trigger a compile error. Currently, the creation of a stub symbol incurs a warning. This commit removes that warning on the basis that it isn't something users need to worry about. javac doesn't emit a comparable warning. The warning is still issued under any of `-verbose` / `-Xdev` / `-Ydebug`.
* | Remove abstraction layer in classpath implementationLukas Rytz2016-05-021-10/+10
| |
* | remove recursive classpath implementationLukas Rytz2016-04-231-1/+1
| |
* | SI-9437 Emit and support parameter names in class filesSimon Ochsenreither2016-01-251-0/+17
| | | | | | | | | | | | | | | | JEP 118 added a MethodParameters attribute to the class file spec which holds the parameter names of methods when compiling Java code with `javac -parameters`. We emit parameter names by default now.
* | SI-8700 Exhaustiveness warning for enums from Java sourceSimon Ochsenreither2016-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Until now, the warning was only emitted for enums from Java class files. This commit fixes it by - aligning the flags set in JavaParsers with the flags set in ClassfileParser (which are required by the pattern matcher to even consider checking exhaustiveness) - adding the enum members as childs to the class holding the enum as done in ClassfileParser so that the pattern matcher sees the enum members when looking for the sealed children of a type
* | Remove ICodeSimon Ochsenreither2015-10-311-1130/+0
|/
* Merge pull request #4653 from lrytz/t9403Jason Zaugg2015-07-272-3/+6
|\ | | | | SI-9403 fix ICodeReader for negative BIPUSH / SIPUSH values
| * SI-9403 fix ICodeReader for negative BIPUSH / SIPUSH valuesLukas Rytz2015-07-242-3/+6
| | | | | | | | | | | | | | | | | | | | | | The byte value of a BIPUSH instruction and the (byte1 << 8) | byte2 value of a SIPUSH instruction are signed, see [1] and [2]. Similar for the increment value of IINC [3]. [1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.bipush [2] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.sipush [3] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.iinc
* | Rename the ENUM / DEFAULTMETHOD flags to include JAVA_Lukas Rytz2015-07-241-1/+1
| | | | | | | | | | Similar to the new JAVA_ANNOTATION flag, be more explicit about flags for java entities.
* | [backport] Fix superclass for Java interface symbols created in JavaMirrorsLukas Rytz2015-07-231-1/+1
|/ | | | | | | | | | According to the spec [1] the superclass of an interface is always Object. Restores the tests that were moved to pending in bf951ec1, fixex part of SI-9374. [1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1
* Merge pull request #4574 from janekdb/2.11.x-typos-g-iJason Zaugg2015-06-231-1/+1
|\ | | | | Fix 25 typos (g-i)
| * Fix 25 typos (g-i)Janek Bogucki2015-06-221-1/+1
| |
* | SI-9359 Fix InnerClass entry flags for nested Java enumsLukas Rytz2015-06-191-0/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | The access flags in InnerClass entries for nested Java enums were basically completely off. A first step is to use the recently introduced backend method `javaClassfileFlags`, which is now moved to BCodeAsmCommon. See its doc for an explanation. Then the flags of the enum class symbol were off. An enum is - final if none of its values has a class body - abstract if it has an abstract method (https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9) When using the ClassfileParser: - ENUM was never added. I guess that's just an oversight. - ABSTRACT (together with SEALED) was always added. This is to enable exhaustiveness checking, see 3f7b8b5. This is a hack and we have to go through the class members in the backend to find out if the enum actually has the `ACC_ABSTRACT` flag or not. When using the JavaParser: - FINAL was never added. - ABSTRACT was never added. This commit fixes all of the above and tests cases (Java enum read from the classfile and from source).
* Merge pull request #4486 from mpociecha/ticket/8679Lukas Rytz2015-05-041-0/+1
|\ | | | | SI-8679 Add support for ScalaLongSignature attribute in scalap
| * SI-8679 Add support for ScalaLongSignature attribute in scalapMichał Pociecha2015-05-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scalap didn't support really big class files. It was returning an empty String for such files. The reason was that there were only ScalaSignatures taken into account. This commit adds support for ScalaLongSignature. We try to get such an attribute when we didn't find ScalaSignature. Also there's added an additional case to the logic retrieving bytes for a signature. Since ScalaLongSignature can contain many parts, we have to merge their byte arrays. Changes are tested by a new partest-based test. These two files are really big, but it was required (t8679.scala is a reduced version of BigScalaClass - an example attached to JIRA). There are also added TODOs with a JIRA ticket: We have three places, where we process Scala signatures. In the future it would be better to reuse some common logic, if it's possible.
* | SI-9282 Avoid obscuring an exception during classfile parsingJason Zaugg2015-04-271-3/+5
|/ | | | | | | | | | | | Based on analysis of a stack trace in this bug report, I identified a code path in `ClassfileParser` that can lead to an NPE in its exception handling code. If `val in = new AbstractFileReader(file)` throws (e.g during its construction in which it eagerly reads the file `val buf: Array[Byte] = file.toByteArray`), the call to `in.file` in `handleError` will NPE. This commit stores the active file directly a field in ClassfileParser and uses this in the error reporting.
* SI-9268 Be robust against absent classfiles during signature parsingJason Zaugg2015-04-211-7/+3
| | | | | | | | | | | | | | When parsing a Java generic signature that references an inner class `A$B`, we were tripping an assertion if the enclosing class `A` was absent. This commit creates a stub symbol for `B` when this happens, rather than continuing on with `NoSymbol`. The enclosed test shows that we can instantiate a class containing a method referring to such an inner class with only a warning about the absent classfile, and that an error is issued only upon a subsequent attempt to call the method.
* Merge pull request #4386 from retronym/ticket/7741Lukas Rytz2015-04-091-8/+14
|\ | | | | SI-7741: Be more tolerant of absent inner classfiles and non-Scala interface members
| * SI-7741 Tread more lightly during classfile parsingJason Zaugg2015-03-251-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Avoid forcing info of non-Scala interface members This avoids parsing the ostensibly malformed class definitions that correspond to a Groovy lambda defined in an interface. 2. Be more tolerant of absent inner classfiles Taking a leaf out of javac's book (see transcript below), we can use stub symbols for InnerClass entries that don't have corresponding class files on the compilation classpath. This will limit failures to code that directly refers to the inner class, rather than any code that simply refers to the enclosing class. It seems that groovyc has a habit of emitting incongrous bytecode in this regard. But this change seems generally useful. ``` % cat sandbox/{Test,Client}.java public class Test { public class Inner {} } public class Client { public Test.Inner x() { return null; } } % javac -d . sandbox/Test.java && javac -classpath . sandbox/Client.java % javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java sandbox/Client.java:2: error: cannot access Inner public Test.Inner x() { return null; } ^ class file for Test$Inner not found 1 error % cat sandbox/{Test,Client}.java public class Test { public class Inner {} } public class Client { public Test.NeverExisted x() { return null; } } % javac -classpath . sandbox/Client.java sandbox/Client.java:2: error: cannot find symbol public Test.NeverExisted x() { return null; } ^ symbol: class NeverExisted location: class Test 1 error % cat sandbox/{Test,Client}.java public class Test { public class Inner {} } public class Client { public Test x() { return null; } } topic/groovy-interop ~/code/scala2 javac -d . sandbox/Test.java && rm 'Test$Inner.class' && javac -classpath . sandbox/Client.java # allowed ```
* | Removed warningsEECOLOR2015-03-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Added `since` to deprecation statement - Added unit to parameter list - Removed usage of deprecated method polyType - Replaced deprecated `debugwarn` with `devWarning` - Changed switch statement to if else in order to remove a warning - Switched implementation of `init` and `processOptions` to prevent warning - Replaced deprecated `Console.readLine` with `scala.io.StdIn.readLine` - Replaced deprecated `startOrPoint` with `start` - Replaced deprecated `tpe_=` with `setType` - Replaced deprecated `typeCheck` with `typecheck` - Replaced deprecated `CompilationUnit.warning` with `typer.context.warning` - Replaced deprecated `scala.tools.nsc.util.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader` - Replaced deprecated `scala.tools.ListOfNil` with `scala.reflect.internal.util.ListOfNil` - Replaced deprecated `scala.tools.utils.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader` - Replaced deprecated `emptyValDef` with `noSelfType` - In `BoxesRunTime` removed unused method and commented out unused values. Did not delete to keep a reference to the values. If they are deleted people might wonder why `1` and `2` are not used. - Replaced deprecated `scala.tools.nsc.util.AbstractFileClassLoader` with `scala.reflect.internal.util.AbstractFileClassLoader`
* | new{Term,Type}Name→{Term,Type}Name, tpename/nme→{type,term}NamesSimon Ochsenreither2015-03-262-2/+2
|/
* Fix many typos in docs and commentsmpociecha2014-12-141-2/+2
| | | | | | | | | | | | | 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.
* Abstract over ClassPath and ClassRepmpociecha2014-11-282-8/+7
| | | | | | | | | | | | | | | | | | | | | | This commit is intended to create the possibility to plug in into the compiler an alternative classpath representation which would be possibly more efficient, use less memory etc. Such an implementation - at least at the beginning - should exist next to the currently existing one and be possible to turn on using a flag. Several places in the compiler have a direct dependency on the classpath implementation. Examples include backend's icode generator and reader, SymbolLoaders, ClassfileParser. After closer inspection, one realizes that all those places depend only on a very small subset of classpath logic: they need to lookup classes from classpath. Hence there's introduced ClassFileLookup trait that encapsulates that functionality. The ClassPath extends that trait and an alternative one also must do it. There's also added ClassRepresentation - the base trait for ClassRep (the inner class of ClassPath). Thanks to that the compiler uses a type which is not directly related to the particular classpath representation as it was doing until now.
* Rename ClassPath.findSourceFile to ClassPath.findClassFileGrzegorz Kossakowski2014-09-242-3/+3
| | | | | | | If you look at the implementation of that method and its usage its clear that it should have been named `findClassFile` from the beginning because that's what it does: find a class file and not a source file.
* Merge pull request #3867 from lrytz/t8708Lukas Rytz2014-07-091-1/+10
|\ | | | | SI-8708 Fix pickling of LOCAL_CHILD child of sealed classes
| * SI-8708 Fix pickling of LOCAL_CHILD child of sealed classesLukas Rytz2014-07-071-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | When a sealed class or trait has local children, they are not pickled in as part of the children of the symbol (introduced in 12a2b3b to fix Aladdin bug 1055). Instead the compiler adds a single child class named LOCAL_CHILD. The parents of its ClassInfoType were wrong: the first parent should be a class. For sealed traits, we were using the trait itself. Also, the LOCAL_CHILD dummy class was entered as a member of its enclosing class, which is wrong: it represents a local (non-member) class, and it's a synthetic dummy anyway.
* | Rip out reporting indirection from CompilationUnitAdriaan Moors2014-07-041-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inline the forwarders from CompilationUnit, which should not affect behavior. Since all forwarders lead to global.reporter, don't first navigate to a compilation unit, only to then forward back to global.reporter. The cleanup in the previous commits revealed a ton of confusion regarding how to report an error. This was a mechanical search/replace, which has low potential for messing things up, since the list of available methods are disjoint between `reporter` and `currentRun.reporting`. The changes involving `typer.context` were done previously. Essentially, there are three ways to report: - via typer.context, so that reporting can be silenced (buffered) - via global.currentRun.reporting, which summarizes (e.g., deprecation) - via global.reporter, which is (mostly) stateless and straightforward. Ideally, these should all just go through `global.currentRun.reporting`, with the typing context changing that reporter to buffer where necessary. After the refactor, these are the ways in which we report (outside of typer): - reporter.comment - reporter.echo - reporter.error - reporter.warning - currentRun.reporting.deprecationWarning - currentRun.reporting.incompleteHandled - currentRun.reporting.incompleteInputError - currentRun.reporting.inlinerWarning - currentRun.reporting.uncheckedWarning Before: - c.cunit.error - c.enclosingUnit.deprecationWarning - context.unit.error - context.unit.warning - csymCompUnit.warning - cunit.error - cunit.warning - currentClass.cunit.warning - currentIClazz.cunit.inlinerWarning - currentRun.currentUnit.error - currentRun.reporting - currentUnit.deprecationWarning - currentUnit.error - currentUnit.warning - getContext.unit.warning - getCurrentCUnit.error - global.currentUnit.uncheckedWarning - global.currentUnit.warning - global.reporter - icls.cunit.warning - item.cunit.warning - reporter.comment - reporter.echo - reporter.error - reporter.warning - reporting.deprecationWarning - reporting.incompleteHandled - reporting.incompleteInputError - reporting.inlinerWarning - reporting.uncheckedWarning - typer.context.unit.warning - unit.deprecationWarning - unit.echo - unit.error - unit.incompleteHandled - unit.incompleteInputError - unit.uncheckedWarning - unit.warning - v1.cunit.warning All these methods ended up calling a method on `global.reporter` or on `global.currentRun.reporting` (their interfaces are disjoint). Also clean up `TypeDiagnostics`: inline nearly-single-use private methods.
* Don't crash on dead code in ICodeReaderLukas Rytz2014-06-041-20/+28
|
* Merge commit 'ec05aeb' into topic/merge-2.10.xJason Zaugg2014-05-081-3/+7
|\
| * SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`Jason Zaugg2014-03-251-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And update the java `ClassFileParser` to create distinguished `StubClassSymbol`s, rather that a regular `ClassSymbol`s, when encountering a deficient classpath. This brings it into line with `Unpickler`, which has done as much since a55788e275f. This stops the enclosed test case from crashing when determining if the absent symbol, `A_1`, is a subclass of `@deprecated`. This is ostensibly fixes a regression, although it only worked in `2.10.[0-3]` by a fluke: the class file parser's promiscious exception handling caught and recovered from the NPE introduced in SI-7439! % javac -d /tmp test/files/run/t8442/{A,B}_1.java && qbin/scalac -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala && (rm /tmp/A_1.class; true) && scalac-hash v2.10.0 -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala warning: Class A_1 not found - continuing with a stub. warning: Caught: java.lang.NullPointerException while parsing annotations in /tmp/B_1.class two warnings found
* | SI-6732 deprecates internal#Symbol.isPackageEugene Burmako2014-02-141-2/+2
| | | | | | | | | | | | | | | | This is the first step in disentangling api#Symbol.isPackage, which is supposed to return false for package classes, and internal#Symbol.isPackage, which has traditionally being used as a synonym for hasPackageFlag and hence returned true for package classes (unlike isModule which is false for module classes).
* | Merge remote-tracking branch 'origin/master' into topic/palladium0Eugene Burmako2014-02-141-2/+5
|\ \
| * | SI-8244 Fix raw type regression under separate compilationJason Zaugg2014-02-121-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In #1901, handling of raw types encountered in signatures during class file parsing was changed to work in the same manner as `classExistentialType`, by using `existentialAbstraction(cls.tparms, cls.tpe_*)` But this never creates fresh existential symbols, and just sticks the class type parameters it `quantified`: scala> trait T[A <: String] defined trait T scala> val cls = typeOf[T[_]].typeSymbol cls = trait T#101864 scala> cls.typeParams res0 = List(type A#101865) scala> cls.tpe_* res1 = T#101864[A#101865] scala> classExistentialType(cls) res3 = T#101864[_ <: String#7209] scala> val ExistentialType(quantified, result) = res3 List(type A#101865) In the enclosed test case, this class type parameter was substituted during `typeOf[X] memberType sym`, which led us unsoundly thinking that `Raw[_]` was `Raw[X]`. I've added a TODO comment to review the other usages of `classExistentialType`. Test variations include joint and separate compilation, and the corresponding Scala-only code. All fail with type errors now, as we expect. I've also added a distillation of a bootstrap error that failed when I forgot to wrap the `existentialType`.
* | | disambiguates uses of “local” in internal symbol APIEugene Burmako2014-02-121-6/+6
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Optimize the pickler phaseJason Zaugg2014-01-311-15/+18
| | | | | | | | | | | | | | | | - move "erroneous type" diagnostic into a crash recovery handler, rather than running it proactively - move the "unexpanded macros" check into refchecks. Cuts this phase in half, from about 1% of compile time to 0.5%.
* | Merge pull request #3368 from retronym/ticket/8151Grzegorz Kossakowski2014-01-211-3/+2
|\ \ | | | | | | SI-8151 Remove -Yself-in-annots and associated implementation