| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`class B(x: X) extends A(x)` uses `x` in ctor,
where it is detectable as an ordinary param.
`implicit class C(val s: String)` may not
use `s` in extension methods, so don't warn.
Don't warn required args to main method.
Don't warn about synthetic isDefinedAt in
anonymous functions, or about defaultCase$.
|
|\
| |
| | |
Don't use `equals` for comparing java.lang.Double/Float
|
| |
| |
| |
| |
| |
| |
| | |
Fixes https://github.com/scala/scala-dev/issues/329
The `equals` method for java.lang.Double/Float behaves differently than comparing
the `doubleValue`s / `floatValues` for `-0.0`/`0.0`/`NaN`.
|
|/
|
|
|
|
|
|
|
| |
Although this is cheap, when debugging log output of info
transformer activity this was a major source of noise.
This commit avoids the info lookup for methods other
than `+`, and then for `+` uses the typer phase info
to distinguish concatentation from addition.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Miscellania:
Miscellania is a small island off the northernmost part
of the Fremennik Isles - RunScape Wiki
Miscellanea:
A collection of miscellaneous objects or writings - Merriam-Webster
|
|\
| |
| | |
SI-10069 Fix code gen errors with array updates, Nothing
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Crashes in ASM or VerifyErrors used to occur when assigning
an expression of type Nothing to an element of a primitive array.
This commit adapts the RHS of the assignment to the element
type to correct this. `adapt` contains logic to insert an
`ATHROW` of the slot of type `Nothing$`, which makes everything
line up. The subsequent array stores become dead code and are
dropped later on in code gen, so the test case compiles to:
public void foo0(double[]);
Code:
0: bipush 42
2: istore_2
3: aload_1
4: iconst_0
5: aload_0
6: invokevirtual #30 // Method throwExpected:()Lscala/runtime/Nothing$;
9: athrow
I found a similar bug in the emission of primitive unboxing and
fixed that too.
|
| |
| |
| |
| |
| |
| | |
Based on review suggestion by retronym.
See also scala/scala-dev#213
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 8020cd6, the inliner was changed to make sure trait methods bodies
are not duplicated into the static super accessors, and from there into
mixin forwarders.
The check for mixin forwarders was too wide. In `def t = super.m`, where
`m` is a trait method annotated `@inline`, we want to inline `m`. Note
that `super.m` is translated to an `invokestatic T.m$`. The current
check incorrectly identifies `t` as a mixin forwarder, and skip
inlining.
|
|\ \
| | |
| | | |
SI-8779 Enable inlining of code within a REPL session
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The REPL has a long running instance of Global which outputs
classfiles by default to a VirtualDirectory. The inliner did not find
any of these class files when compiling calls to methods defined in
previous runs (ie, previous lines of input.)
This commit:
- Adds a hook to augment the classpath that the optimizer searches,
and uses this in the REPL to add the output directory
- Fixes the implementation of `findClassFile` in VirtualDirectory,
which doesn't seem to have been used in anger before. I've factored out
some common code into a new method on `AbstractFile`.
- Fixes a similar problem getSubDir reported by Li Haoyi
- Adds missing unit test coverage.
This also fixes a bug in REPL autocompletion for types defined
in packages >= 2 level deep (with the `:paste -raw` command).
I've added a test for this case.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
One line per inline request, nested inlines are indented. Log when a
rollback happens. Examples:
```
Inline into scala/collection/SeqLike$$anon$2.andThen: inlined scala/collection/SeqLike$$anon$2.andThen. Before: 8 ins, inlined: 8 ins.
inlined scala/PartialFunction.andThen$. Before: 20 ins, inlined: 8 ins.
inlined scala/PartialFunction.andThen. Before: 31 ins, inlined: 10 ins.
```
and
```
Inline into scala/collection/IterableLike$$anon$1.takeWhile: inlined scala/collection/IterableLike$$anon$1.takeWhile. Before: 8 ins, inlined: 8 ins.
inlined scala/collection/TraversableViewLike.takeWhile$. Before: 20 ins, inlined: 8 ins.
failed scala/collection/TraversableViewLike.takeWhile. [...] would cause IllegalAccessError [...]
rolling back, nested inline failed.
```
|
| |
| |
| |
| |
| | |
Rename `undoLog.run` to `rollback`, use java ArrayList instead of
helper methods to copy to an array.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When re-writing a closure invocation to the body method, the `itf` flag
of the invocation instruction was incorrect: it needs to be true if
the method is defined in an interface (including static methdos), not
if the method is invoked through `INVOKEINTERFACE`.
JDK 8 doesn't flag this inconsistency and executes the bytecode, but the
verifier in JDK 9 throws an `IncompatibleClassChangeError`.
Similar fixes went into e619b03.
|
|\
| |
| | |
SD-233 synchronized blocks are JIT-friendly again
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GenBCode, the new backend in Scala 2.12, subtly changed
the way that synchronized blocks are emitted.
It used `java/lang/Throwable` as an explicitly named exception
type, rather than implying the same by omitting this in bytecode.
This appears to confuse HotSpot JIT, which reports a error
parsing the bytecode into its IR which leaves the enclosing method
stuck in interpreted mode.
This commit passes a `null` descriptor to restore the old pattern
(the same one used by javac.) I've checked that the JIT warnings
are gone and that the method can be compiled again.
|
|/
|
|
|
|
|
| |
... by calling javaBinaryNameString, instead.
They all are happy with a throw away String, there is no advantage
to interning this into the name table.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
decompile classfiles in parallel to aid in diffing bytecode between quick & strap
```
mkdir class-repo
cd class-repo
git init .
( cd .. ; sbt publishLocal )
v="2.12.0-local-$(g rev-parse --short HEAD)" ( cd ~/git/scala-2 ; sbt -Dstarr.version=$v compile )
for i in compiler interactive junit library partest-extras partest-javaagent reflect repl repl-jline repl-jline-embedded scaladoc scalap
do
cp -a ~/git/scala/build/quick/classes/$i .
~/git/scala/build/quick/bin/scala scala.tools.nsc.backend.jvm.AsmUtils $(find $i -name "*.class" )
g add $(find $i -name "*.asm" )
done
g commit -m"quick"
for i in compiler interactive junit library partest-extras partest-javaagent reflect repl repl-jline repl-jline-embedded scaladoc scalap
do
cp -a ~/git/scala-2/build/quick/classes/$i/* $i/
~/git/scala/build/quick/bin/scala scala.tools.nsc.backend.jvm.AsmUtils $(find $i -name "*.class" )
done
git --no-pager diff | mate
```
|
|\
| |
| | |
SI-5294 SI-6161 Hard graft in asSeenFrom, refinements, and existentials [ci: last-only]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Lazy base type seq elements are encoded as a refined type with
an empty scope and a list of type refs over some common type
symbol that will be merged when `BaseTypeSeq#apply` is called.
The first change in this commit is to mark the creation and consumption
of such elements with calls to `[is]IntersectionTypeForBaseTypeSeq`. They
are distinguished by using the actual type symbol rather than a refinement
class symbol, which in turn simplifies the code in
`BaseTypeSeq#typeSymbol`.
I have also made `lub` aware of this encoding: it is now able to "see through"
to the parents of such refined types and merge them with other base types
of the same class symbol (even other refined types representing lazy BTS
elements.)
To make this fix work, I also had to fix a bug in LUBs of multiple with
existential types. Because of the way the recursion was structured in
`mergePrefixAndArgs`, the order of list of types being merged changed
behaviour: quantified varialbles of existential types were being rewrapped
around the resultting type, but only if we hadn't encountered the first
regular `TypeRef`.
This can be seen with the following before/after shot:
```
// 2.11.8
scala> val ts = typeOf[Set[Any]] :: typeOf[Set[X] forSome { type X <: Y; type Y <: Int}] :: Nil; def merge(ts: List[Type]) = mergePrefixAndArgs(ts, Variance.Contravariant, lubDepth(ts)); val merged1 = merge(ts); val merged2 = merge(ts.reverse); (ts.forall(_ <:< merged1), ts.forall(_ <:< merged2))
ts: List[$r.intp.global.Type] = List(Set[Any], Set[_ <: Int])
merge: (ts: List[$r.intp.global.Type])$r.intp.global.Type
merged1: $r.intp.global.Type = scala.collection.immutable.Set[_ >: Int]
merged2: $r.intp.global.Type = scala.collection.immutable.Set[_53] forSome { type X <: Int; type _53 >: X }
res0: (Boolean, Boolean) = (false,true)
// HEAD
...
merged1: $r.intp.global.Type = scala.collection.immutable.Set[_10] forSome { type X <: Int; type _10 >: X }
merged2: $r.intp.global.Type = scala.collection.immutable.Set[_11] forSome { type X <: Int; type _11 >: X }
res0: (Boolean, Boolean) = (true,true)
```
Furthermore, I have fixed the computation of the base type sequences of
existential types over refinement types, in order to maintain the invariant
that each slot of the base type sequence of a existential has the same
type symbol as that of its underlying type. Before, what I've now called
a `RefinementTypeRef` was transformed into a `RefinedType` during
rewrapping in the existential, which led to it being wrongly considered as
a lazy element of the base type sequence. The first change above should
also be sufficient to avoid the bug, but I felt it was worth cleaning up
`maybeRewrap` as an extra line of defence.
Finally, I have added another special case to `BaseTypeSeq#apply` to
be able to lazily compute elements that have been wrapped in an existential.
The unit test cases in `TypesTest` rely on these changes. A subsequent commit
will build on this foundation to make a fix to `asSeenFrom`.
|
|\ \
| |/
|/| |
SD-194 Tweak module initialization to comply with JVM spec
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Top level modules in Scala currently desugar as:
```
class C; object O extends C { toString }
```
```
public final class O$ extends C {
public static final O$ MODULE$;
public static {};
Code:
0: new #2 // class O$
3: invokespecial #12 // Method "<init>":()V
6: return
private O$();
Code:
0: aload_0
1: invokespecial #13 // Method C."<init>":()V
4: aload_0
5: putstatic #15 // Field MODULE$:LO$;
8: aload_0
9: invokevirtual #21 // Method java/lang/Object.toString:()Ljava/lang/String;
12: pop
13: return
}
```
The static initalizer `<clinit>` calls the constructor `<init>`, which
invokes superclass constructor, assigns `MODULE$= this`, and then runs
the remainder of the object's constructor (`toString` in the example
above.)
It turns out that this relies on a bug in the JVM's verifier: assignment to a
static final must occur lexically within the <clinit>, not from within `<init>`
(even if the latter is happens to be called by the former).
I'd like to move the assignment to <clinit> but that would
change behaviour of "benign" cyclic references between modules.
Example:
```
package p1; class CC { def foo = O.bar}; object O {new CC().foo; def bar = println(1)};
// Exiting paste mode, now interpreting.
scala> p1.O
1
```
This relies on the way that we assign MODULE$ field after the super class constructors
are finished, but before the rest of the module constructor is called.
Instead, this commit removes the ACC_FINAL bit from the field. It actually wasn't
behaving as final at all, precisely the issue that the stricter verifier
now alerts us to.
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; object O
// Exiting paste mode, now interpreting.
scala> val O1 = p1.O
O1: p1.O.type = p1.O$@ee7d9f1
scala> scala.reflect.ensureAccessible(p1.O.getClass.getDeclaredConstructor()).newInstance()
res0: p1.O.type = p1.O$@64cee07
scala> O1 eq p1.O
res1: Boolean = false
```
We will still achieve safe publication of the assignment to other threads
by virtue of the fact that `<clinit>` is executed within the scope of
an initlization lock, as specified by:
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.5
Fixes scala/scala-dev#SD-194
|
|/
|
|
|
|
| |
Rather than putting the code of a trait method body into a static method,
leave it in the default method. The static method (needed as the target
of the super calls) now uses `invokespecial` to exactly call that method.
|
|\
| |
| |
| |
| | |
SD-20 Inlcude static methods in the InlineInfo in mixed compilation
Fixes scala/scala-dev#20
|
| |
| |
| |
| |
| |
| |
| |
| | |
In mixed compilation, the InlineInfo for a Java-defined class is created
using the class symbol (vs in separate compilation, where the info is
created by looking at the classfile and its methods). The scala compiler
puts static java methods into the companion symbol, and we forgot to
include them in the list of methods in the InlineInfo.
|
|\ \
| | |
| | | |
SD-193 Lock down lambda deserialization
|
| | |
| | |
| | |
| | |
| | | |
- Remove unused references to "addTargetMethods"
- Require that `targetMethodMap` is provided
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The old design allowed a forged `SerializedLambda` to be
deserialized into a lambda that could call any private method
in the host class.
This commit passes through the list of all lambda impl methods
to the bootstrap method and verifies that you are deserializing
one of these.
The new test case shows that a forged lambda can no longer call
the private method, and that the new encoding is okay with a large
number of lambdas in a file.
We already have method handle constants in the constant pool
to support the invokedynamic through LambdaMetafactory, so
the only additional cost will be referring to these in
the boostrap args for `LambdaDeserialize`, 2 bytes per lambda.
I checked this with an example:
https://gist.github.com/retronym/e343d211f7536d06f1fef4b499a0a177
Fixes SD-193
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There isn't much point to the late* flags in a world where
we're mutating flags left and right in tree and info transformers...
So, lets get rid of the indirection until we can include flags
in a symbol's type history, like we do for its info.
This retires lateDEFERRED (redundant with SYNTHESIZE_IMPL_IN_SUBCLASS).
Since it's introduced so late, it makes little sense to have these
synthetic members go back to DEFERRED. Instead, just set DEFERRED directly.
Also remove unused late* and not* flags.
notPRIVATE subsumes lateFINAL for effective finality (scala/scala-dev#126)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One step towards teasing apart the mixin phase, making
each phase that adds members to traits responsible for
mixing in those members into subclasses of said traits.
Another design tenet is to not emit symbols or trees
only to later remove them. Therefore, we model a
val in a trait as its accessor. The underlying field
is an implementation detail. It must be mixed into
subclasses, but has no business in a trait (an interface).
Also trying to reduce tree creation by changing less in subtrees
during tree transforms.
A lot of nice fixes fall out from this rework:
- Correct bridges and more precise generic signatures for
mixed in accessors, since they are now created before erasure.
- Correct enclosing method attribute for classes nested in trait fields.
Trait fields are now created as MethodSymbol (no longer TermSymbol).
This symbol shows up in the `originalOwner` chain of a class declared
within the field initializer. This promoted the field getter to
being the enclosing method of the nested class, which it is not
(the EnclosingMethod attribute is a source-level property).
- Signature inference is now more similar between vals and defs
- No more field for constant-typed vals, or mixed in accessors
for subclasses. A constant val can be fully implemented in a trait.
TODO:
- give same treatment to trait lazy vals (only accessors, no fields)
- remove support for presuper vals in traits
(they don't have the right init semantics in traits anyway)
- lambdalift should emit accessors for captured vals in traits,
not a field
Assorted notes from the full git history before squashing below.
Unit-typed vals: don't suppress field
it affects the memory model -- even a write of unit to a field is relevant...
unit-typed lazy vals should never receive a field
this need was unmasked by test/files/run/t7843-jsr223-service.scala,
which no longer printed the output expected from the `0 to 10 foreach`
Use getter.referenced to track traitsetter
reify's toolbox compiler changes the name of the trait
that owns the accessor between fields and constructors (`$` suffix),
so that the trait setter cannot be found when doing mkAssign in constructors
this could be solved by creating the mkAssign tree immediately during fields
anyway, first experiment: use `referenced` now that fields runs closer
to the constructors phase (I tried this before and something broke)
Infer result type for `val`s, like we do for `def`s
The lack of result type inference caused pos/t6780 to fail
in the new field encoding for traits, as there is no separate accessor,
and method synthesis computes the type signature based on the ValDef tree.
This caused a cyclic error in implicit search, because now the
implicit val's result type was not inferred from the super member,
and inferring it from the RHS would cause implicit search to consider
the member in question, so that a cycle is detected and type checking fails...
Regardless of the new encoding, we should consistently infer result types
for `def`s and `val`s.
Removed test/files/run/t4287inferredMethodTypes.scala and test/files/presentation/t4287c,
since they were relying on inferring argument types from "overridden" constructors
in a test for range positions of default arguments. Constructors don't override,
so that was a mis-feature of -Yinfer-argument-types.
Had to slightly refactor test/files/presentation/doc, as it was relying
on scalac inferring a big intersection type to approximate the anonymous
class that's instantiated for `override lazy val analyzer`.
Now that we infer `Global` as the expected type based on the overridden val,
we make `getComment` private in navigating between good old Skylla and Charybdis.
I'm not sure why we need this restriction for anonymous classes though;
only structural calls are restricted in the way that we're trying to avoid.
The old behavior is maintained nder -Xsource:2.11.
Tests:
- test/files/{pos,neg}/val_infer.scala
- test/files/neg/val_sig_infer_match.scala
- test/files/neg/val_sig_infer_struct.scala
need NMT when inferring sig for accessor
Q: why are we calling valDefSig and not methodSig?
A: traits use defs for vals, but still use valDefSig...
keep accessor and field info in synch
|
|\ \ \
| | | |
| | | | |
SD-48 limit the lenght of inlined local variable names
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
When inlining local variables, the names are prefixed with the callee
method name. In long chains of inlining, these names can grow
indefinitely. This commits introduces a limit.
|
| |/
|/| |
|
|\ \
| | |
| | | |
Deprecate @remote
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead, we follow the example set by javac, and predicate serializability
of bot anon-class and invokedynamic-based lambdas on whether or not the
SAM type extends java.io.Serializable.
Fixes https://github.com/scala/scala-dev/issues/120
|
| |/
|/|
| |
| |
| | |
The constructor of scala.tools.asm.Handle now takes an additional
boolean parameter to denote whether the owner is an interface.
|
|\ \
| | |
| | | |
Right-bias Either
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Add operations like map, flatMap which assume right-bias
- Deprecate {Left,Right}Projection
- Deprecate left and right in favor of swap
- Add contains, toOption, toTry, toSeq and filterOrElse
- toSeq returns collection.immutable.Seq instead of collection.Seq
- Don't add get
There are no incompatible changes.
The only possibility of breakage that exists is when people have added
extension methods named map, flatMap etc. to Either in the past doing
something different than the methods added to Either now.
One detail that moved the scales in favor of deprecating LeftProjection
and RightProjection was the desire to have toSeq return
scala.collection.immutable.Seq instead of scala.collection.Seq
like LeftProjection and RightProjection do.
Therefore keeping LeftProjection and RightProjection would introduce
inconsistency.
filter is called filterOrElse because filtering in a for-comprehension
doesn't work if the method needs an explicit argument.
contains was added as safer alternative to
if (either.isRight && either.right.get == $something) ...
While adding filter with an implicit zero value is possible, it's
dangerous as it would require that developers add a "naked" implicit
value of type A to their scope and it would close the door to a future
in which the Scala standard library ships with Monoid and filter could
exist with an implicit Monoid parameter.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
Also logged in as SD-162
The optimizer had conservative checks in place to perform closure
elimination only for Scala Function types. We can eliminate IndyLambda
instructions for any functional interface. LambdaMetaFactory only
constructs lambda objects for interface types, which don't have any
side-effects on construction - they don't have a constructor.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
And use this as the target of the default methods or
statically resolved super or $init calls.
The call-site change is predicated on `-Yuse-trait-statics`
as a stepping stone for experimentation / bootstrapping.
I have performed this transformation in the backend,
rather than trying to reflect this in the view from
Scala symbols + ASTs.
We also need to add an restriction related to invokespecial to Java
parents: to support a super call to one of these to implement a
super accessor, the interface must be listed as a direct parent
of the class.
The static method names has a trailing $ added to avoid duplicate
name and signature errors in classfiles.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
So far, line numbers were kept only when inlining from the same class.
We can also keep them when inlining from a different class defined in
the same compilation unit.
Longer-term we should support JSR-45, see SI-7518 and scala-dev#3.
|
| |
| |
| |
| |
| |
| |
| | |
For classes being compiled (vs. being loaded from classfiles), keep the
source file path in the bytecode repo. This will allow to keep line
numbers when inlining from one class into another in case the two are
defined in the same compilation unit.
|