summaryrefslogtreecommitdiff
path: root/src/compiler/scala/tools/nsc/symtab
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.
* | Fix regression in 5751763Iulian Dragos2017-02-221-5/+10
|/ | | | | | | | | | enterClass/Module may return an existing symbol, but in 5751763 the return value was dropped leading to assertion failures. This may show up only in the presentation compiler, which explains why it went unnoticed. Here's what needs to happen: - a class with a companion is loaded by the IDE, but the class name is different than the file name. This is from source - the same class and companion object exist as binary, and are loaded from classfiles when the package is completed (since they have different names than the source file, the classpath abstraction will only "know" that there is a classfile, and no corresponding source file) It seems that companionClass always prefers to return the companion defined in a source file, but if this assertion is called from the code path that tries to load the binary version, the newly created module will not match.
* 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. ```
| * [backport] Replace println with log calls in BrowsingLoadersIulian Dragos2016-10-251-4/+4
| | | | | | | | | | | | | | This alternative symbol loader is used in the presentation compiler and may generate output even when the compiler should be silent. See SI-8717 for more context, even though this does not really fix the ticket.
* | 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-282-34/+34
| | | | | | | | | | | | | | | | | | | | | | | | 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-272-30/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Replace println with log calls in BrowsingLoadersIulian Dragos2016-10-191-4/+4
|/ / | | | | | | | | | | | | This alternative symbol loader is used in the presentation compiler and may generate output even when the compiler should be silent. See SI-8717 for more context, even though this does not really fix the ticket.
* | 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-022-19/+17
| |
* | remove recursive classpath implementationLukas Rytz2016-04-232-36/+3
| |
* | 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).
* Fix some typos (a-c)Janek Bogucki2015-06-181-1/+1
|
* SI-9322 Elapsed times in compiler calculated withSean Riggin2015-05-261-2/+1
| | | | | | | | System.currentTimeMillis and System.nanoTime Reverted elapsedTime calculation in compiler to use System.currentTimeMillis, consistent with the start time.
* 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-142-3/+3
| | | | | | | | | | | | | 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-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Define interface for flat classpath and add package loader using itmpociecha2014-11-301-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the base trait for flat classpath - an alternative classpath representation. In accordance with the idea and the experimental implementation of @gkossakowski, this representation will try to make the best use of the specificity of a given file type instead of using AbstractFile everywhere. It's possible as .NET backend is no longer supported and we can focus on Java-specific types of files. FlatClassPath extends ClassFileLookup which provides the common interface used also by existing ClassPath. The new implementation is called flat because it's possible to query the whole classpath using just single instance. In the case of the old (recursive) representation there's the structure of nested classpath objects, where each such an object can return only entries from one level of hierarchy but it returns also another classpath objects for nested levels included in it. That's why there's added dedicated PackageLoaderUsingFlatClassPath in SymbolLoaders - approaches are different so also the way of loading packages has to be different. The new package loader is currently unused. There's added also PackageNameUtils which will provide common methods used by classpath implementations for various file types.
* Abstract over ClassPath and ClassRepmpociecha2014-11-283-11/+10
| | | | | | | | | | | | | | | | | | | | | | 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 #3826 from lrytz/opt/refactorTrackedGrzegorz Kossakowski2014-07-251-12/+29
|\ | | | | Assortiment of cleanups and comments around the backend
| * Clean up and document some usages of flags in the backendLukas Rytz2014-07-081-12/+29
| |
* | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-23 18:33:09 +0000