| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Companion detection consults the scopes of enclosing Contexts during
typechecking to avoid the cycles that would ensue if we had to look
at into the info of enclosing class symbols. For example, this used
to typecheck:
object CC { val outer = 42 }
if ("".isEmpty) {
case class CC(c: Int)
CC.outer
}
This logic was not suitably hardened to find companions in exactly
the same nesting level.
After fixing this problem, a similar problem in `Namer::inCurrentScope`
could be solved to be more selective about synthesizing a companion
object. In particular, if a manually defined companion trails after
the case class, don't create an addiotional synthetic comanpanion object.
|
|\
| |
| | |
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.)
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
The utility method compares javaSpecVersion, which has the
form "1.8" previously and "9" going forward.
The method accepts "1.n" for n < 9. More correctly, the string
argument should be a single number.
Supports JEP-223.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
just in time for Halloween. "boostrap" is definitely the most
adorable typo evah -- and one of the most common, too. but we don't
want to scare anybody.
|
| | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Replace println with log calls in BrowsingLoaders
|
| | |/ / / / / / /
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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.
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
No warn when discarding r.f(): r.type
|