| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
-Ydebug is supposed to show everything about the phases,
including full description (if otherwise clipped) and
any phases that are not "enabled" by options.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes fields fit the field width, which is fitting.
`s/including/add` seems sufficient.
Possibly, "synthesize" is an extravagance for "add",
but "add" is used previously in that column.
Resolve, load, translate, add, synthesize, replace, erase,
move, eliminate, remove, generate.
Would love to learn a word that says what typer does, if
the word "type" is too redundant or overloaded, besides the
food metaphor. Also "meat-and-potatoes" implies basic,
simple, not fussy or fancy. There are many devices,
like the heart or a Ferrari engine, that are
fundamental without being unfussy.
|
| |\
| |
| | |
Make output of errors in testAll less verbose
|
| | | |
|
| |\ \
| | |
| | | |
expunge a stray reference to sbaz in the Scala man page
|
| | |/
| |
| |
| | |
and fix a typo while we're at it
|
| |\ \
| | |
| | | |
SI-9936 SeqLike.indexWhere starts at zero
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This follows the Scaladoc, and makes
```
"abcdef".indexOf('c', -1)
```
work like
```
"abcdef".toVector.indexOf('c', -1)
```
|
| |\ \ \
| | | |
| | | | |
use proper lightbend.com and scala-sbt.org URLs
|
| | |/ /
| | |
| | |
| | |
| | | |
not dl.bintray.com, it's an implementation detail that they're
our current provider
|
| |\ \ \
| |/ /
|/| | |
Bump sbt-jmh version to 0.2.16
|
| | |/
| |
| |
| |
| |
| |
| | |
It'd be good to use the latest version. From sbt-jmh version 0.2.10,
Flight Recorder / Java Mission Control is available[1], which would be nice.
[1] https://github.com/ktoso/sbt-jmh#using-oracle-flight-recorder
|
| |\ \
| |/
|/| |
Only compare group ID and artifact ID when looking for JLine JAR
|
| |/
|
|
|
|
| |
If the JLine dependency is resolved through Ivy instead of Maven (which
can happen with a local proxy setup in sbt that funnels all artifacts
through an Ivy repo), the artifact may have a “configuration” set,
which prevents a naive comparison of ModuleIDs from finding it.
|
| |\
| |
| | |
bump STARR to 2.12.0-RC1
|
| |/ |
|
| |\
| |
| | |
Spec typo: hide source comment in rendered version
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
SD-208 Restore 2.11 names for arrayOps implicits
Fix scala/scala-dev#208
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Discussion: https://github.com/sbt/sbt/issues/2722
This commit checks that some test events exist in the
test log for `test/it:test` before trusting the result
of `Success`.
|
| |\ \ \
| | | |
| | | | |
SD-143 allow super calls to methods defined in indirect super classes
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The restriction for super calls to methods defined in indirect super
classes introduced in a980fde was over-restrictive. In particular, it
ruled out a valid code pattern to select a method from a superclass
when an unqualified `super` would resolve to an override defined in a
trait (example in the commit as a test).
|
| |\ \ \
| |_|/
|/| | |
Remove ant
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Remove ant scripts.
- Remove shell scripts that were specific to the ant build or the old
`*.desired.sha1` binary artifact management.
- Remove `build.number`.
- Remove `src/build/maven` and `src/build/bnd`. The POM and Manifest
metadata is generated in a different way by sbt.
|
| |\ \ \
| |/ /
|/| | |
More elegant holders for local lazy vals.
|
| |/ / |
|
| |\ \
| | |
| | | |
Fixes to mixin forwarders
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
JUnit 4 does not support default methods. For better user experience,
this commit makes the compiler generate mixin forwarders for inherited
trait methods that carry a JUnit annotation.
The -Yjunit-trait-methods-no-forwarders flag disables this behavior.
This supersedes the scala-js/scala-2.12-junit-mixin-plugin compiler
plugin.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a call super[T].m resolves to a method A.m where A is a class, but
not the direct superclass of the current class, there is no way to
emit an invocation of A.m: `invokespecial A.m` will resolve to B.m
where B is the superclass of the current class.
This commit adds an error message in this case.
Note that this is similar to an existing error message for qualified
super calls to a non-direct superclass:
class A { def m = 1 }
class B extends A { override def m = 2 }
class C extends B { override def m = super[A].m }
Gives "error: A does not name a parent class of class C".
If the user means to call method m in the superclass, he can write an
unqualified `super.m`.
An similar error message is introduced if A is a Java-defined interface
(and m is a default method), and A is not a direct parent of the current
class. In this case `invokespecial A.m` is invalid bytecode. The
solution is to add A as a direct parent of the current class.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With -Xgen-mixin-forwarders the compiler eagerly creates mixin
forwarders for methods inherited from traits, even if the JVM method
resolution would pick the correct default method.
When generating a such a forwarder for a Java-defined default method,
the mixin forwarder invokes the default method directly using
`invokespecial` (for Scala-defined trait methods, the forwarder uses
the static `m$` method that is generated for every trait method).
An `invokespecial` call is only legal if the named interface is a
direct parent of the current class. If this is not the case, we don't
generate the mixin forwarder and emit a warning.
In the tests there's also an example where a mixin forwarder is
required for correctness, but cannot be added because the corresponding
`invokespecial` call would be invalid. In this case we emit an error.
This is similar to what we already do for other super calls to Java-
defined default methods. The difference is that the super call is not
written by the user but generated by the mixin forwarder. The solution
is the same: add the interface as a direct parent.
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Fields: expand lazy vals during fields, like modules
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now `synchronized` is erased specially to avoid boxing,
we can drop that work around.
Note that this does add an extra cast and getter
call on the slow path, but that likely doesn't matter.
```
class C { def foo = {lazy val x = {println("a"); "A" }; x } }
```
becomes
```
def foo(): String = {
lazy <artifact> val x$lzy: scala.runtime.LazyRef[String] = new scala.runtime.LazyRef[String]();
<artifact> private def x$lzycompute(): String =
x$lzy.synchronized[String]{
if (x$lzy.initialized())
x$lzy.value() // NOTE: gets an `.asInstanceOf[String]` after erasure
else
{
x$lzy.value_=({
scala.Predef.println("a");
"A"
});
x$lzy.initialized_=(true);
x$lzy.value() // NOTE: gets an `.asInstanceOf[String]` after erasure
}
}
lazy def x(): String =
if (x$lzy.initialized())
x$lzy.value() // NOTE: gets an `.asInstanceOf[String]` after erasure
else
x$lzycompute();
x()
}
```
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Mostly refactorings and catching up with doc updates.
Some changes to flag handling, removing some redundancy,
and making lazy fields and modules a bit more consistent
in their flags. They now uniformly carry LAZY or MODULEVAR.
Before, LAZY was dropped because mixin had some lazy val
logic. No longer.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The goal is to avoid emitting unneeded `BoxedUnit` values,
which are the result of adapting a `Unit`-typed expression
inside a `synchronized(...)` to the erased type of
`synchronized`'s argument -- `Object`.
The proposed solution gives `synchronized` a polymorphic
type (the info of the type param is still erased so that
bounds checking works in the erased type system), so that
an application `synchronized(println("boo"))` erases to
`synchronized[Unit])(println("boo"))`, and no boxing is
performed on the `println("boo")` argument, whose expected
type is now `Unit` instead of `Object`.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Inline `mkSynchronizedCheck`, whose abstraction obscured rather than clarified.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since we need to refer to a trait lazy val's accessor using a
super call in a subclass (when the field and bitmap are added),
we must ensure that access is allowed.
If the lazy val has an access boundary (e.g., `private[somePkg]`),
make sure the `PROTECTED` flag is set, which widens access
to `protected[somePkg]`. (As `member.hasAccessBoundary` implies
`!member.hasFlag(PRIVATE)`, we don't have to `resetFlag PRIVATE`.)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Essentially, we fuse mixin and lazyvals into the fields phase.
With fields mixing in trait members into subclasses, we
have all info needed to compute bitmaps, and thus we can
synthesize the synchronisation logic as well.
By doing this before erasure we get better signatures,
and before specialized means specialized lazy vals work now.
Mixins is now almost reduced to its essence: implementing
super accessors and forwarders. It still synthesizes
accessors for param accessors and early init trait vals.
Concretely, trait lazy vals are mixed into subclasses
with the needed synchronization logic in place, as do
lazy vals in classes and methods. Similarly, modules
are initialized using double checked locking.
Since the code to initialize a module is short,
we do not emit compute methods for modules (anymore).
For simplicity, local lazy vals do not get a compute method either.
The strange corner case of constant-typed final lazy vals
is resolved in favor of laziness, by no longer assigning
a constant type to a lazy val (see widenIfNecessary in namers).
If you explicitly ask for something lazy, you get laziness;
with the constant-typedness implicit, it yields to the
conflicting `lazy` modifier because it is explicit.
Co-Authored-By: Lukas Rytz <lukas@lightbend.com>
Fixes scala/scala-dev#133
Inspired by dotc, desugar a local `lazy val x = rhs` into
```
val x$lzy = new scala.runtime.LazyInt()
def x(): Int = {
x$lzy.synchronized {
if (!x$lzy.initialized) {
x$lzy.initialized = true
x$lzy.value = rhs
}
x$lzy.value
}
}
```
Note that the 2.11 decoding (into a local variable and a bitmap) also
creates boxes for local lazy vals, in fact two for each lazy val:
```
def f = {
lazy val x = 0
x
}
```
desugars to
```
public int f() {
IntRef x$lzy = IntRef.zero();
VolatileByteRef bitmap$0 = VolatileByteRef.create((byte)0);
return this.x$1(x$lzy, bitmap$0);
}
private final int x$lzycompute$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
C c = this;
synchronized (c) {
if ((byte)(bitmap$0$1.elem & 1) == 0) {
x$lzy$1.elem = 0;
bitmap$0$1.elem = (byte)(bitmap$0$1.elem | 1);
}
return x$lzy$1.elem;
}
}
private final int x$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
return (byte)(bitmap$0$1.elem & 1) == 0 ?
this.x$lzycompute$1(x$lzy$1, bitmap$0$1) : x$lzy$1.elem;
}
```
An additional problem with the above encoding is that the `lzycompute`
method synchronizes on `this`. In connection with the new lambda
encoding that no longer generates anonymous classes, captured lazy vals
no longer synchronize on the lambda object.
The new encoding solves this problem (scala/scala-dev#133)
by synchronizing on the lazy holder.
Currently, we don't exploit the fact that the initialized field
is `@volatile`, because it's not clear the performance is needed
for local lazy vals (as they are not contended, and as soon as
the VM warms up, biased locking should deal with that)
Note, be very very careful when moving to double-checked locking,
as this needs a different variation than the one we use for
class-member lazy vals. A read of a volatile field of a class
does not necessarily impart any knowledge about a "subsequent" read
of another non-volatile field of the same object. A pair of
volatile reads and write can be used to implement a lock, but it's
not clear if the complexity is worth an unproven performance gain.
(Once the performance gain is proven, let's change the encoding.)
- don't explicitly init bitmap in bytecode
- must apply method to () explicitly after uncurry
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of doing this lazily, rework the logic to
make it suitable for operating first on symbols
(during the info transform), then on trees (tree transform).
|
| | | | | |
|
