| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to inline a final trait method, callsites of such methods are
first re-written from interface calls to static calls of the trait's
implementation class. Then inlining proceeds as ususal.
One problem that came up during development was that mixin methods are
added to class symbols only for classes being compiled, but not for
others. In order to inline a mixin method, we need the InlineInfo,
which so far was built using the class (and method) symbols. So we had
a problem with separate compilation.
Looking up the symbol from a given classfile name was already known to
be brittle (it's also one of the weak points of the current inliner),
so we changed the strategy. Now the InlineInfo for every class is
encoded in a new classfile attribute.
This classfile attribute is relatively small, because all strings it
references (class internal names, method names, method descriptors)
would exist anyway in the constant pool, so it just adds a few
references.
When building the InlineInfo for a class symbol, we only look at the
symbol properties for symbols being compiled in the current run. For
unpickled symbols, we build the InlineInfo by reading the classfile
attribute.
This change also adds delambdafy:method classes to currentRun.symSource.
Otherwise, currentRun.compiles(lambdaClass) is false.
|
|
|
|
|
|
|
|
|
|
| |
Note that JUnit creates a new instance of the test class for running
each test method. So the compiler instance is added to the companion.
However, the JVM would quickly run out of memory when running multiple
tests, as the compilers cannot be GCd. So we make it a `var`, and set
it to null when a class is done. For that we use JUnit's `@AfterClass`
which is required to be on a static method. Therefore we add a Java
class with such a static method that we can extend from Scala.
|
|
|
|
|
|
| |
The test is corrected (inverted) and the extractor is made
more succinct. Succinctness isn't enforced by the test,
but I checked it manually.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous behavior was to iterate over the mutated
list of arbitrary length. The previous iteration of
the iterator would also iterate the terminal element
of the list without halting.
This is fixed by capping the length of iterator.
That is OK because mutating the list by adding to it during
iteration is not recommended.
For good measure, the exhausted iterator does not hold
a reference to any remaining tail.
A test is added that will no doubt be superseded by the QCC tests.
(Quasi-Comprehensive Collections.)
The test just checks that the extra tail is not strongly
reachable from the iterator. If the garbage collector happens
to kick in and determine that the object is weakly reachable,
then the check terminates early.
|
|
|
|
|
|
|
|
|
|
| |
Without loss of generality or convenience, but helps
reduce the number of files in test/files and may reduce
compile times for test suite.
This commit includes the fix from #3963 and an extra
test of that fix that ensures the stack doesn't grow
on chained drops.
|
|
|
|
| |
JUnit tests may use tools from partest-extras (ASMConverters)
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
This is much easier to use than built-in JUnit method-level checks.
|