| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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`
|
| |
|
|
|
|
| |
... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
|
|\
| |
| | |
SI-9127 Xlint doesn't think spaces are significant
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For purposes of warning about missing interpolators,
such as `"$greeting"` when the intended code was `s"$greeting"`,
spaces are no longer significant.
The heuristic was previously intended to allow compileresque
strings, where the dollar sign is a common prefix.
Currently, the Xlint warning can be selectively disabled.
|
|\ \
| | |
| | | |
Improve diagnostic error on failed genLoadIdent
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This error has been haunting us recently, firstly on Greg's machine
when compiling the compiler using the new SBT build, and more recently
during PR validation in #4316.
This commit will output an error like:
symbol value c#16812 does not exist in Macro.impl, which contains locals value a#16810, value b#16811
I've included symbol IDs in the hope that they will prove useful.
It seems that synthetic identifiers generated by the pattern matcher
are often seen in the vicinity of this bug.
|
|\ \ \
| | | |
| | | | |
SI-9020 Avoid spurious value discarding warning post-typer
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Typechecking during the specialization phase was emitting a
bogus warning about value discarding. Such warnings in the
typer should be guarded by `!isPastTyper` to restrict the
analysis to the code the user originally wrote, rather than
the results of later typechecking.
I've made this change to the value discarding warning. I've also
changed a numeric widening warning in the vicinity, although I do
not have a test case for that.
|
|\ \ \ \
| | | | |
| | | | | |
SI-9170 More flexible SessionTest
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
SessionTest session text can include line continuations
and pasted text. Pasted script (which looks like a
double prompt) probably doesn't work.
This commit includes @retronym's SI-9170 one-liner.
|
|\ \ \ \
| | | | |
| | | | | |
SI-9231 Don't attempt implicit search for erroneous parameter
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the instantiated type of an implicit parameter is erroneous,
we should not attempt the implicit search. This avoids the following
useless error message in the enclosed test:
error: ambiguous implicit values: ... match expected type M[<error>]
|
|\ \ \ \
| | | | |
| | | | | |
SI-9102: Reflect method invoke with mixed args
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Cover the second use case reported on the ML (ctors).
Improve formatting per the review. And it really does look
a lot better.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
A missing default branch when a method had value class
or by-name params caused other args to present as null
under reflective invocation.
|
|\ \ \ \ \
| |_|_|_|/
|/| | | | |
SI-9219 Stream toString returns unexpected result
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Cursor was not advanced before appending the second element
when only the first two elements of the stream were known.
- When there is no cycle in the stream, the "scout" (and
"cursor") ends up pointing to a stream where tailDefined
is false. This means that cursor is either empty, or
cursor.tail is not yet evaluated. The former case is handled
properly, but in the latter case, one more element
(cursor.head) needs to be appended.
|
|\ \ \ \
| | | | |
| | | | | |
Performance optimization - SeqLike
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Big improvements to updated and patch by not creating intermediate collections.
Moderate improvement to sorted by not using extra ArraySeq wrapper.
Small improvements to diff, intersect, and padTo by watching for duplicate or slow operations a bit more carefully.
```
Performance summary (all timings JDK 1.8.0_25 Linux):
method reason
=========== ===============================================================
diff 1.1x speedup on big seqs - avoid double map lookup
intersect 1.1-1.2x speedup - avoid double map lookup
padTo avoid multiple calls to length (good if length is slow)
patch 2.4-4.0x speedup - avoid intermediate collections
sorted 1.2-1.5x speedup - use array directly
updated 3.5-9.6x speedup - avoid intermediates (but children override)
```
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Inliner for GenBCode
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Method bodies that contain a super call cannot be inlined into other
classes. The same goes for methods containing calls to private
methods, but that was already ensured before by accessibility checks.
The last case of `invokespecial` instructions is constructor calls.
Those can be safely moved into different classes (as long as the
constructor is accessible at the new location).
Note that scalac never emits methods / constructors as private in
bytecode.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The inliner would incorrectly treat trait field accessors like
ordinary trait member methods and try to re-write invocations to the
corresponding static method in the implementation class. This rewrite
usually failed because no method was found in the impl class.
However, for lazy val fields, there exists a member in the impl class
with the same name, and the rewrite was performed. The result was that
every field access would execute the lazy initializer instead of
reading the field.
This commit checks the traitMethodWithStaticImplementation field of
the ScalaInlineInfo classfile attribute and puts an explicit
`safeToRewrite` flag to each call site in the call graph. This cleans
up the code in the inliner that deals with rewriting trait callsites.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Issue precise warnings when the inliner fails to inline or analyze a
callsite. Inline failures may have various causes, for example because
some class cannot be found on the classpath when building the call
graph. So we need to store problems that happen early in the optimizer
(when building the necessary data structures, call graph, ClassBTypes)
to be able to report them later in case the inliner accesses the
related data.
We use Either to store these warning messages. The commit introduces
an implicit class `RightBiasedEither` to make Either easier to use for
error propagation. This would be subsumed by a biased either in the
standard library (or could use a Validation).
The `info` of each ClassBType is now an Either. There are two cases
where the info is not available:
- The type info should be parsed from a classfile, but the class
cannot be found on the classpath
- SI-9111, the type of a Java source originating class symbol cannot
be completed
This means that the operations on ClassBType that query the info now
return an Either, too.
Each Callsite in the call graph now stores the source position of the
call instruction. Since the call graph is built after code generation,
we build a map from invocation nodes to positions during code gen and
query it when building the call graph.
The new inliner can report a large number of precise warnings when a
callsite cannot be inlined, or if the inlining metadata cannot be
computed precisely, for example due to a missing classfile.
The new -Yopt-warnings multi-choice option allows configuring inliner
warnings.
By default (no option provided), a one-line summary is issued in case
there were callsites annotated @inline that could not be inlined.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I observed cases (eg Scaladoc tests) where we end up with 17k+
ClassNodes, which makes 500 MB.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The self parameter type may be incompatible with the trait type.
trait T { self: S => def foo = 1 }
The $self parameter type of T$class.foo is S, which may be unrelated
to T. If we re-write a call to T.foo to T$class.foo, we need to cast
the receiver to S, otherwise we get a VerifyError.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The inliner forces some method symbols to complete that would not be
completed otherwise. This triggers SI-9111, in which the completer of
a valid Java method definition reports an error in mixed compilation.
The workaround disables error reporting while completing lazy method
and class symbols in the backend.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In mixed compilation, the bytecode of Java classes is not availalbe:
the Scala compiler does not produce any, and there are no classfiles
yet.
When inlining a (Scala defined) method that contains an invocation to
a Java method, we need the Java method's bytecode in order to check
whether that invocation can be transplanted to the new location
without causing an IllegalAccessError. If the bytecode cannot be
found, inlining won't be allowed.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Building the call graph and running the inliner require all code to
be reachable (in terms of ASM's data flow analysis / interpreter).
After removing unreachable code, empty exception handlers need to be
removed for correctness (see comment in LocalOpt.methodOptimizations).
Removing a live exception handler renders its handler unreachable and
therefore requires running another round of removing unreachable code.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The `ByteCodeRepository.classNode(InternalName)` method now returns an
option. Concretely, in mixed compilation, the compiler does not create
a ClassNode for Java classes, and they may not exist on the classpath
either.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The current heuristics are simple: attempt to inline every method
annotated `@inline`. Cycles in the inline request graph are broken
in a determinisitc manner. Inlining is then performed starting at the
leaves of the inline request graph, i.e., with those callsites where
the target method has no callsites to inline.
This expansion strategy can make a method grow arbitrarily. We will
most likely have to add some thresholds and / or other measures to
prevent size issues.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Inlining decisions will be taken by analyzing the ASM bytecode. This
commit adds tools to build a call graph representation that can be
used for these decisions.
The call graph is currently built by considering method descriptors of
callsite instructions. It will become more precise by using data flow
analyses.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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 method Inliner.inline clones the bytecode of a method and copies
the new instructions to the callsite with the necessary modifications.
See comments in the code.
More tests are added in a later commit which integrates the inliner
into the backend - tests are easier to write after that.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Some instructions would cause an IllegalAccessError if they are
inlined into a different class.
Based on Miguel's implementation in 6efc0528c6.
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9223 By-name constructor params should not be aliased
|
| | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Usually, the compiler tries avoids creating a field in a subclass
for a constructor parameter that is known to be stored in a field
in one of its superclasses.
However, in the enclosed test `run/t9223.scala`, this mechanism
confuses `=> A` with `A`, which results in a runtime
`ClassCastException`.
This commit avoids using param aliases for by-name parameters.
I have also added a test for something close the opposite case, where
the subclass has a strict parameter and the superclass has a by-name
parameter. This was working correctly before this patch.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Upgrade ASM to 5.0.3
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This commit is a squashed version of all commits in PR #4382.
For the next upgrade, consult the src/asm/README and check the commits
in https://github.com/scala/scala/pull/4382/commits.
|
| |/ / / / / |
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On 2.11.6 line 535 (as reported in the issue) points to the changed
line.
Exception.getMessage can return null. Checking for null on the matched
variable is not necessary.
No tests, because I have no idea on how to reproduce the problem.
|
|\| | | |
| |_|/ /
|/| | | |
Emit the ScalaInlineInfo attribute under GenASM
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The goal of this commit is to allow the new inliner (in GenBCode,
coming soon) to inline methods generated by the GenASM backend of
2.11.6.
The ScalaInlineInfo attribute is added to every classfile generated
by GenASM. It contains metadata about the class and its methods that
will be used by the new inliner.
Storing this metadata to the classfile prevents the need to look up a
class symbol for a certain class file name, a process that is known to
be brittle due to name mangling. Also, some symbols are not exactly
the same when originating in a class being compiled or an unpickled
one. For example, method symbols for mixed-in members are only added
to classes being compiled.
The classfile attribute is relatively small, because all strings it
references (class internal names, method names, method descriptors)
would exist anyway in the constant pool. It just adds a few references
and bits for each method in the classfile.
Jar sizes before:
480142 scala-actors.jar
15531408 scala-compiler.jar
5543249 scala-library.jar
4663078 scala-reflect.jar
785953 scalap.jar
After:
490491 scala-actors.jar (102.1%)
15865500 scala-compiler.jar (102.1%)
5722504 scala-library.jar (103.2%)
4788370 scala-reflect.jar (102.7%)
805890 scalap.jar (102.5%)
|
|\ \ \
| | | |
| | | | |
Merge 2.10.x to 2.11.x
|
| |\ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | | |
Conflicts:
src/library/scala/concurrent/Promise.scala
test/files/jvm/future-spec/PromiseTests.scala
|
| | |\ \
| | | | |
| | | | | |
SI-8689 Avoid internal error in Promise after sequence of completions
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Calling `completeWith` when the `DefaultPromise` is already completed,
leads to callbacks not being properly executed.
This happened because `Future.InternalCallbackExecutor` extends
`BatchingExecutor`[1] which assumes `unbatchedExecute` to be async,
when in this case it is sync, and if there is an exception thrown
by executing the batch, it creates a new batch with the remaining
items from the current batch and submits that to `unbatchedExecute`
and then rethrows, but if you have a sync `unbatchedExecute`, it will
fail since it is not reentrant, as witnessed by the failed `require`
as reported in this issue.
This commit avoids problem by delegating `completeWith` to
`tryComplete`, which has the effect of using `onComplete` +
`tryComplete` i.s.o. `complete`, which means that when it fails
(because of a benign race condition between completers) it won't
throw an exception.
It has been tested by the minimized reproducer.
[1] Actually, in the 2.10.x branch where this patch is starting out,
"The BatchingExecutor trait had to be inlined into
InternalCallbackExecutor for binary compatibility.". This comment
will be more literally correct in the context of 2.11.x and beyond
|
| | |/ / |
|