| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Avoid triple-quoting triple quotes in printer
|
| | |
| |
| |
| |
| | |
Since octal escape is deprecated, use unicode escape
for string representation of constants.
|
| |\ \
| | |
| | | |
SI-9849 set privateWithin on default getters
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A default getter get the same access flag (private / protected) as the
method whose default it implements. However, we forgot to set the
privateWithin flag, which defines the scope in a qualified private /
protected modifier.
For a private[p], the default getter was therefore public, which is less
restricted (a private[p] method has privateWithin set to p, but the
private flag is not set). For a protected[p], the default getter was
protected, which is more restricted.
|
| |\ \ \
| | | |
| | | | |
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.
|
| |\ \ \ \
| |_|/ /
|/| | | |
Fix typo in test comment
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This was throwing a UnsupportedOperationError for small operations.
The parallel collections test suite sets `-minSuccessfulTests 5` in
test/files/scalacheck/parallel-collections/pc.scala, which is far
lower thatn the default of 100, and means that we are less likely
to falsify properties.
This parameter seems to have been added in #2476, assuming I'm reading
it correctly. Not sure of the motiviation, perhaps just to make the
slowest part of the scalacheck test suite run faster?
I haven't changed the paramater now, but instead have included a one
element collection in generator.
I also found that when the test failed, Scalacheck would try to minimize
the example, but did so assuming that the elements of the tuple of
test data could be independentally shrunk. This breaks the invariant
that the two collections contain equal elements, and led to spurious
error reports. I have disabled shrinking in all tests tests affected
by this.
|
| |\ \ \
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fresh name for catcher gets a dollar. "Here, have a dollar."
Test due to retronym demonstrates possible conflict.
Over the lifetime of the universe, surely at least one code
monkey would type in that identifier to catch a banana.
|
| |\ \ \
| | | |
| | | | |
SI-9390 Emit local defs that don't capture this as static
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
An existing optimization in `Constructors` elides the outer
field in member and local classes, if the class doesn't use
the outer reference. (Member classes also need to be final,
which is a secret handshake to say we're also happy to weaken
prefix matching in the pattern matcher.)
That optimization leaves the constructor signature as is: the
constructor still accepts the outer instance, but does not store
it. For member classes, this means that we can separately compile
code that calls the constructor.
Local classes need not be hampered by this constraint, we could
remove the outer instance from the constructor call too.
Why would we want to do this?
Let's look at the case before and after this commit.
Before:
```
class C extends Object {
def foo(): Function1 = $anonfun();
final <static> <artifact> def $anonfun$foo$1($this: C, x: Object): Object = new <$anon: Object>($this);
def <init>(): C = {
C.super.<init>();
()
}
};
final class anon$1 extends Object {
def <init>($outer: C): <$anon: Object> = {
anon$1.super.<init>();
()
}
}
```
After:
```
class C extends Object {
def foo(): Function1 = $anonfun();
final <static> <artifact> def $anonfun$foo$1(x: Object): Object = new <$anon: Object>(null);
def <init>(): C = {
C.super.<init>();
()
}
};
final class anon$1 extends Object {
def <init>($outer: C): <$anon: Object> = {
anon$1.super.<init>();
()
}
}
```
However, the status quo means that a lambda that
This in turn makes lambdas that refer to such classes serializable
even when the outer class is not itself serialiable.
I have not attempted to extend this to calls to secondary constructors.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This avoids unnecessary memory retention, and allows lambdas
that call the local methods to be serializable, regardless of
whether or not the enclosing class is serializable.
The second point is especially pressing, given that the enclosing
class for local methods defined in a used to be the (serializable)
anonymous function class, but as of Scala 2.12 will be the enclosing
class of the lambda.
This change is similar in spirit to SI-9408 / 93bee55e.
|
| |\| | |
| | | |
| | | | |
Lambda impl methods static and more stably named
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The body of lambdas is compiled into a synthetic method
in the enclosing class. Previously, this method was a public
virtual method named `fully$qualified$Class$$anonfun$n`.
For lambdas that didn't capture a `this` reference, a static
method was used.
This commit changes two aspects.
Firstly, all lambda impl methods are now emitted static.
An extra parameter is added to those that require a this
reference.
This is an improvement as it:
- allows, shorter, more readable names for the lambda impl method
- avoids pollution of the vtable of the class. Note that javac uses
private instance methods, rather than public static methods. If
we followed its lead, we would be unable to support important use
cases in our inliner
Secondly, the name of the enclosing method has been included in
the name of the lambda impl method to improve debuggability and
to improve serialization compatibility. The serialization improvement
comes from the way that fresh names for the impl methods are
allocated: adding or removing lambdas in methods not named "foo" won't
change the numbering of the `anonfun$foo$n` impl methods from methods
named "foo". This is in line with user expectations about anonymous
class and lambda serialization stability. Brian Goetz has described
this tricky area well in:
http://cr.openjdk.java.net/~briangoetz/eg-attachments/lambda-serialization.html
This commit doesn't go as far a Javac, we don't use the hash of the
lambda type info, param names, etc to map to a lambda impl method name.
As such, we are more prone to the type-1 and -2 failures described there.
However, our Scala 2.11.8 has similar characteristics, so we aren't going
backwards.
Special case in the naming: Use "new" rather than "<init>" for constructor enclosed
lambdas, as javac does.
I have also changed the way that "delambdafy target" methods are identifed.
Rather than relying on the naming convention, I have switched to using a
symbol attachment. The assumption is that we only need to identify them
from within the same compilation unit.
This means we can distinguish impl metbods for expanded functions
(ones called from an `apply` method of an ahead-of-time expanded
anonfun class), from those that truly end up as targets for lambda
metafactory. Only the latter are translated to static methods in
this patch.
|
| |\ \ \ \
| | | | |
| | | | | |
Prohibit @native method in trait
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On the JVM, a @native interface method results in a VerifyError.
Other platforms could decide to be more permissive, but it seems
like allowing them in classes is enough.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8667 Improve too-many-args message
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Pick the first excessive positional arg for the caret.
Note that erroring on named args doesn't do the obvious thing
in this regard.
If `k` was removed from the signature, then `f(k=1, i=2, j=3)`
doesn't tell us much about the wrong arg, because naming takes
the `k=1` as an assignment, `i` as duplicate naming. No arg is
deemed extra, though further inspection of the conflicting args
might get there. Since assignment syntax in parens is more|less
deprecated (?), no more effort is done here.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use removeNames to help diagnose the application.
Supplement the error message with how many extra
args and any other residual assignments that the
user might have thought was a properly named arg.
The error message is gradual: succinct for short
arg lists, more verbose for longer applications.
Very long arg lists are probably generated, so
that message is the least colloquial.
|
| | |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If `-raw` is not supplied explicitly to REPL `:paste`,
see if the code text starts with `package` keyword or
else see if it parses to a named package (to cope with
leading commentary). In that case, take it as raw.
But parse only on suspect comment slash.
It's only worth parsing for a package if there's a chance
that package keyword is buried behind comments.
Small refactors to the `paste` object.
|
| |\ \ \ \ \
| | |_|/ /
| |/| | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-7898 Read user input during REPL warmup
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Text-based REPL pre-parses, so use the current label for errors.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use a "label" for errors, so that script names are shown.
Position is still wrong for scripts in REPL.
Initial scripts are run with `ILoop.echo` and results printing
turned off, but reporter still enabled.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The compiler is created on main thread and user input is read
on an aux thread (opposite to currently).
Fixes completion when `-i` is supplied.
Now `-i` means pasted and new option `-I` means line-by-line.
The temporary reader uses postInit to swap in the underlying
reader.
Completion is disabled for the temporary reader, rather than
blocking while it waits for a compiler. But manically hitting
tab is one way of knowing exactly when completion is live.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
Use jarlister in build
|
| | | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The goal of this change is to exercize the "manifest classpath" mechanism,
meant to bring the compiler its needed classes as resources, listed
in jar manifests, as opposed to files, thus enabling to use the compiler
in sandboxed environments (and also the scripting engine for that matter).
|
| |\| | | | | |
|
| | |\ \ \ \ \
| | |/ / / /
| |/| | | | |
SI-4625 Recognize App in script
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixed the warning when main module is accompanied by snippets.
Minor clean-up so even I can follow what is returned.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It's pretty confusing when your script object becomes a local
and then nothing happens. Such as when you're writing a test and
it takes forever to figure out what's going on.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In an unwrapped script, where a `main` entry point is discovered
in a top-level object, retain all top-level classes.
Everything winds up in the default package.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Cheap name test: if the script object extends "App",
take it for a main-bearing parent.
Note that if `-Xscript` is not `Main`, the default,
then the source is taken as a snippet and there is
no attempt to locate an existing `main` method.
|
| |\| | | | |
| |_|_|/ /
|/| | | | |
|
| | |/ / /
| | | |
| | | |
| | | | |
Follow-up for https://github.com/scala/scala/pull/4117
|
| |\ \ \ \
| | | | |
| | | | | |
Improvements to deprecations related to `since` parameter
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-9382 Privatize enhanced x in Tuple2Zipped.Ops
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Consolated JUnit tests and heeded comment about private def and
code beauty.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Probably there should be an Abide rule to avoid leaking
the "underlying value" of a value class. The spec or SIP defines
"underlying type" but doesn't mention the underlying value.
The argument for concealing the member is that it is redundant
and makes autocompletion results harder to read. Also, possibly
an additional implicit might want to add a member so-named.
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
SI-9794 Error advice uses decoded method name
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
So much work went into polishing this error message,
it's worth buffing the method name when it's an operator.
The message now says `+` instead of `$plus`.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-2712 Add support for partial unification of type constructors
|
| | | | | | | | |
|
