| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some changes to the trait encoding came late in the 2.12 cycle, and the
inliner was not adapted to support it in the best possible way.
In 2.12.0 concrete trait methods are encoded as
interface T {
default int m() { return 1 }
static int m$(T $this) { <invokespecial $this.m()> }
}
class C implements T {
public int m() { return T.m$(this) }
}
If a trait method is selected for inlining, the 2.12.0 inliner would
copy its body into the static super accessor `T.m$`, and from there into
the mixin forwarder `C.m`.
This commit special-cases the inliner:
- We don't inline into static super accessors and mixin forwarders.
- Insted, when inlining an invocation of a mixin forwarder, the
inliner also follows through the two forwarders and inlines the
trait method body.
There was a difficulty implementing this: inlining the static static
super accessor would copy an `invokespecial` instruction into a
different classfile, which is not legal / may change semantics. That
`invokespecial` is supposed to disappear when inlining the actual
default method body. However, this last step may fail, for example
because the trait method body itself contains instructions that are not
legal in a different classfile.
It is very difficult to perform all necessary checks ahead of time. So
instead, this commit implements the ability to speculatively inline a
callsite and roll back if necessary.
The commit also cleans up the implementation of inliner warnings a
little. The previous code would always emit a warning when a method
annotated `@inline` was not picked by the heuristics - this was a
problem when the callsite in the static super accessor was no longer
chosen.
|
| |\
| |
| | |
SI-9814 Fix synchronized in specialized overrides
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Specialization creates a subclasses of a specializd class for each
type parameter combination. These contains copies of the methods from
the superclass.
However, before this transform, the pattern of self-synchronization
in a method body had been replace by flag Flag.SYNCHRONIZED on the
method symbol. This was not being propagated to the override, and
hence no locking occured.
This commit modifies the creation of the specialized overload symbol
to copy the SYNCHRONIZED flag, as was already done for ASBOVERRIDE.
I have also done the same for the `@strictfp` annotation.
|
| |\ \
| | |
| | | |
SI-6412 remove flaky test
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I have repeatedly seen this fail CI runs, including recently
as the comment in the test itself says: "I'm not sure this is a great
way to test for memory leaks, since we're also testing how good
the JVM's GC is, and this is not easily reproduced between
machines/over time"
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
SI-10007 sys.process thread sync
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A previous change to replace `SyncVar.set` with `SyncVar.put`
breaks things.
This commit tweaks the thread synchronizing in `sys.process`
to actually use `SyncVar` to sync and pass a var.
Joining the thread about to exit is superfluous.
A result is put exactly once, and consumers use
non-destructive `get`.
Note that as usual, avoid kicking off threads in a static
context, since class loading cycles are somewhat dicier
with 2.12 lambdas. In particular, REPL is a static context
by default.
SI-10007 Clarify deprecation message
The message on `set` was self-fulfilling, as it didn't
hint that `put` has different semantics.
So explain why `put` helps avoid errors instead of
creating them.
SI-10007 Always set exit value
Always put a value to exit code, defaulting to None.
Also clean up around tuple change to unfortunately
named Future.apply. Very hard to follow those types.
Date command pollutes output, so tweak test.
|
| |\ \ \ \
| |_|_|/
|/| | | |
SI-9885 Don't return offset past EOF
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
On bad line number, `lineToOffset` should not return
an offset past EOF (which was sentinel, internally).
|
| |\ \ \ \
| | | | |
| | | | | |
Reinstate MiMa and address problems
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 656162bb48fbbd703790a2c94d4563e40ddfdfc2.
Adding new APIs is not possible until a major release.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-9953 Any Any aborts warn on equals
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Don't warn about equals if any `Any` is involved. cf SI-8965
The condition for warning is that both types lub to a supertype
of Object.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9944 Scan after interp expr keeps CR
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In an interpolated expression `s"""${ e }"""`, the scanner
advances input past the RBRACE. If a multiline string as
shown, get the next raw char, because CR is significant.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9915 Fix test on windows
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Use `javac: -encoding UTF-8` tool args comment
so javac uses correct source encoding.
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
SI-10059 reset the `DEFERRED` flag for Java varargs forwarders
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When an abstract method is annotated `@varargs`, make sure that the
generated synthetic Java varargs method does not have the `DEFERRED`
flag (`ACC_ABSTRACT` in bytecode).
The flag lead to an NPE in the code generator, because the ASM framework
leaves certain fields `null` for abstract methods (`localVariables` in
this case).
Interestingly this did not crash in 2.11.x: the reason is that the test
whether to emit a method body or not has changed in the 2.12 backend
(in c8e6050).
val isAbstractMethod = [..] methSymbol.isDeferred [..] // 2.11
val isAbstractMethod = rhs == EmptyTree // 2.12
So in 2.11, the varargs forwarder method was actually left abstract in
bytecode, leading to an `AbstractMethodError: T.m([I)I` at run-time.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9915 Utf8_info are modified UTF8
|
| | | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Use DataInputStream.readUTF to read CONSTANT_Utf8_info.
This fixes reading embedded null char and supplementary chars.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Because no one votes against a progressive test.
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-9888. Prevent OOM on ParRange. Improve toString.
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
SI-6978 No linting of Java parens
|
| | | |/ / / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Don't lint overriding of nullary by non-nullary
when non-nullary is Java-defined. They can't help it.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
SI-6734 Synthesize companion near case class
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Tweak the "should I synthesize now" test for
case modules, so that the tree is inserted in
the same tree as the case class.
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
SI-10032 Fix code gen with returns in nested try-finally blocks
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
When a return in a finalizer was reached through a return within the try
block, the backend ignored the return in the finalizer:
try {
try { return 1 }
finally { return 2 }
} finally { println() }
This expression should evaluate to 2 (it does in 2.11.8), but in 2.12.0
it the result is 1.
The Scala spec is currently incomplete, it does not say that a finalizer
should be exectuted if a return occurs within a try block, and it does
not specify what happens if also the finally block has a return.
So we follow the Java spec, which basically says: if the finally blocks
completes abruptly for reason S, then the entire try statement completes
abruptly with reason S. An abrupt termination of the try block for a
different reason R is discarded.
Abrupt completion is basically returning or throwing.
|
| | | |_|_|/ / / / /
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Return statements within `try` or `catch` blocks need special treatement
if there's also a `finally`
try { return 1 } finally { println() }
For the return, the code generator emits a store to a local and a jump
to a "cleanup" version of the finally block. There will be 3 versions
of the finally block:
- One reached through a handler, if the code in the try block
throws; re-throws at the end
- A "cleanup" version reached from returns within the try; reads the
local and returns the value at the end
- One reached for ordinary control flow, if there's no return and no
exception within the try
If there are multiple enclosing finally blocks, a "cleanup" version is
emitted for each of them. The nested ones jump to the enclosing ones,
the outermost one reads the local and returns.
A global variable `shouldEmitCleanup` stores whether cleanup versions
are required for the curren finally blocks. By mistake, this variable
was not reset to `false` when emitting a `try-finally` nested within a
`finally`:
try {
try { return 1 }
finally { println() } // need cleanup version
} finally { // need cleanup version
try { println() }
finally { println() } // no cleanup version needed!
}
In this commit we ensure that the variable is reset when emitting
nested `try-finally` blocks.
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
SI-10034: Regression: Make Future.failed(e).failed turn into a success instead of failure
|
| | |/ / / / / / / / |
|
| |\ \ \ \ \ \ \ \ \
| |/ / / / / / / /
|/| | | | | | | | |
|
| | |\ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
SI-9913 Lead span iterator finishes at state -1
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Even if no elements fail the predicate (so that the trailing
iterator is empty).
|
| |\ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|_|/ /
|/| | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
No StackOverflowError in Java doc comment scanning
Fixes SI-10020 SI-10027
|
| | | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|_|_|/
|/| | | | | | | | | |
Frontend fixes for scala-dev#248
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
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.
|
| | | | | | | | | | | |
|
| | | |_|_|/ / / / /
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This fixes scala/scala-dev#248, where a type alias reached the backend
through this method.
This is very similar to the fix for SI-5031, which changed it only in
ModuleSymbol, but not in Symbol.
The override in ModuleSymbol is actually unnecessary (it's identical),
so it's removed in this commit. It was added for unclear reasons in
296b706.
|
| |\ \ \ \ \ \ \ \ \
| |/ / / / / / / /
|/| | | | | | | | |
SI-9750 scala.util.Properties.isJavaAtLeast works with JDK9
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Don't assume spec is just major, but allow arbitrary version
number for both spec value and user value to check.
Only the first three dot-separated fields are considered,
after skipping optional leading value "1" in legacy format.
Minimal validity checks of user arg are applied. Leading three
fields, if present, must be number values, but subsequent
fields are ignored.
Note that a version number is not a version string, which
optionally includes pre and build info, `9-ea+109`.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
A good opportunity to simplify the API. Versions are strings,
but a spec version is just a number.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Leaves the error string as is, but adds test to show how it looks.
Java calls it a version number. `Not a version: 1.9`.
Don't strip `1.` prefix recursively. (That was Snytt's fault.)
|
