| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
SI-10190 Elide string to empty instead of null
|
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid NPE when eliding string-valued functions.
For example, `log(s"$cheap$expensive")` needn't print null.
This is a natural and inexpensive way to elide strings.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
In refchecks, check that symbol with `@elidable` is a method.
When eliding in uncurry, doublecheck.
The check is enabled under `-Xsource:2.13`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure that methods annotated with varargs are properly mixed-in. This commit
splits the transformation into an info transformer (that works on all symbols, whether
they come from source or binary) and a tree transformer.
The gist of this is that the symbol-creation part of the code was moved to the UnCurry
info transformer, while tree operations remained in the tree transformer. The newly
created symbol is attached to the original method so that the tree transformer can still
retrieve the symbol.
A few fall outs:
- I removed a local map that was identical to TypeParamsVarargsAttachment
- moved the said attachment to StdAttachments so it’s visible between reflect.internal
and nsc.transform
- a couple more comments in UnCurry to honour the boy-scout rule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They remain ValDefs until then.
- remove lazy accessor logic
now that we have a single ValDef for lazy vals,
with the underlying machinery being hidden until the fields phase
leave a `@deprecated def lazyAccessor` for scala-refactoring
- don't skolemize in purely synthetic getters,
but *do* skolemize in lazy accessor during typers
Lazy accessors have arbitrary user code, so have to skolemize.
We exempt the purely synthetic accessors (`isSyntheticAccessor`)
for strict vals, and lazy accessors emitted by the fields phase
to avoid spurious type mismatches due to issues with existentials
(That bug is tracked as https://github.com/scala/scala-dev/issues/165)
When we're past typer, lazy accessors are synthetic,
but before they are user-defined to make this hack less hacky,
we could rework our flag usage to allow for
requiring both the ACCESSOR and the SYNTHETIC bits
to identify synthetic accessors and trigger the exemption.
see also https://github.com/scala/scala-dev/issues/165
ok 7 - pos/existentials-harmful.scala
ok 8 - pos/t2435.scala
ok 9 - pos/existentials.scala
previous attempt: skolemize type of val inside the private[this] val
because its type is only observed from inside the
accessor methods (inside the method scope its existentials are skolemized)
- bean accessors have regular method types, not nullary method types
- must re-infer type for param accessor
some weirdness with scoping of param accessor vals and defs?
- tailcalls detect lazy vals, which are defdefs after fields
- can inline constant lazy val from trait
- don't mix in fields etc for an overridden lazy val
- need try-lift in lazy vals: the assign is not seen in uncurry
because fields does the transform (see run/t2333.scala)
- ensure field members end up final in bytecode
- implicit class companion method: annot filter in completer
- update check: previous error message was tangled up with unrelated
field definitions (`var s` and `val s_scope`),
now it behaves consistently whether those are val/vars or defs
- analyzer plugin check update seems benign, but no way to know...
- error message gen: there is no underlying symbol for a deferred var
look for missing getter/setter instead
- avoid retypechecking valdefs while duplicating for specialize
see pos/spec-private
- Scaladoc uniformly looks to field/accessor symbol
- test updates to innerClassAttribute by Lukas
|
|\
| |
| | |
Introducing: the fields phase [ci: last-only]
|
| |
| |
| |
| |
| |
| |
| | |
We do this during uncurry so we can insert the necessary
applications to the empty argument list. Fields is too late.
Refchecks is no longer an info transform.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating a varargs forwarder for
def foo[T](a: T*)
the parameter type of the forwarder needs to be Array[Object]. If we
gnerate Array[T] in UnCurry, that would be erased to plain Object, and
the method would not be a valid varargs.
Unfortunately, setting the parameter type to Array[Object] lead to
an invalid generic signature - the generic signature should reflect the
real signature.
This change adds an attachment to the parameter symbol in the varargs
forwarder method and special-cases signature generation.
Also cleanes up the code to produce the varargs forwarder. For example,
type parameter and parameter symbols in the forwarder's method type were
not clones, but the same symbols from the original method were re-used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The body of `def delay[T](v: => T) = (v _): F0[T]`
becomes `() => v` during `typedEta`, and then uncurry
considers whether to strip the function wrapper since
`v` is known to be a `Function0` thunk. Stripping is sound
when the expected type is `Function0` for this expression,
but that's no longer a given, since we could be expecting any
nullary SAM.
Also sweep up a bit around `typedEta`.
Encapsulate the, erm, creative encoding of
`m _` as `Typed(m, Function(Nil, EmptyTree))`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than in implementation of the abstract method in the
expanded anonymous class.
This leads to more more efficient use of the constant pool,
code shapes more amenable to SAM inlining, and is compatible
with the old behaviour of `-Xexperimental` in Scala 2.11,
which ScalaJS now relies upon.
Manual test:
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; trait T { val x = 0; def apply(): Any }; class DelambdafyInline { def t: T = (() => "") }
// Exiting paste mode, now interpreting.
scala> :javap -c p1.DelambdafyInline
Compiled from "<pastie>"
public class p1.DelambdafyInline {
public p1.T t();
Code:
0: new #10 // class p1/DelambdafyInline$$anonfun$t$1
3: dup
4: aload_0
5: invokespecial #16 // Method p1/DelambdafyInline$$anonfun$t$1."<init>":(Lp1/DelambdafyInline;)V
8: areturn
public final java.lang.Object p1$DelambdafyInline$$$anonfun$1();
Code:
0: ldc #22 // String
2: areturn
public p1.DelambdafyInline();
Code:
0: aload_0
1: invokespecial #25 // Method java/lang/Object."<init>":()V
4: return
}
scala> :javap -c p1.DelambdafyInline$$anonfun$t$1
Compiled from "<pastie>"
public final class p1.DelambdafyInline$$anonfun$t$1 implements p1.T,scala.Serializable {
public static final long serialVersionUID;
public int x();
Code:
0: aload_0
1: getfield #25 // Field x:I
4: ireturn
public void p1$T$_setter_$x_$eq(int);
Code:
0: aload_0
1: iload_1
2: putfield #25 // Field x:I
5: return
public final java.lang.Object apply();
Code:
0: aload_0
1: getfield #34 // Field $outer:Lp1/DelambdafyInline;
4: invokevirtual #37 // Method p1/DelambdafyInline.p1$DelambdafyInline$$$anonfun$1:()Ljava/lang/Object;
7: areturn
public p1.DelambdafyInline$$anonfun$t$1(p1.DelambdafyInline);
Code:
0: aload_1
1: ifnonnull 6
4: aconst_null
5: athrow
6: aload_0
7: aload_1
8: putfield #34 // Field $outer:Lp1/DelambdafyInline;
11: aload_0
12: invokespecial #42 // Method java/lang/Object."<init>":()V
15: aload_0
16: invokespecial #45 // Method p1/T.$init$:()V
19: return
}
scala> :quit
```
Adriaan is to `git blame` for `reflection-mem-typecheck.scala`.
|
|
|
|
|
|
|
|
|
|
|
| |
LambdaMetaFactory can only properly instantiate Java interfaces
(with one abstract method, of course). A trait always compiles
to an interface, but a subclass that can be instantiated may
require mixing in further members, which LMF cannot do.
(Nested traits, traits with fields,... do not qualify.)
Traits that cannot be instantiated by LMF are still SAM targets,
we simply created anonymous subclasses as before.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a SAM type is specialized (i.e., a specialized type
parameter receives a specialized type argument), do not use
LambdaMetaFactory (expand during Uncurry instead).
This is an implementation restriction -- the current
specialization scheme is not amenable to using
LambdaMetaFactory to spin up subclasses. Since the generic
method is abstract, and the specialized ones are concrete,
specialization is rendered moot because we cannot implement
the specialized method with the lambda using LMF.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the earlier proposals were too strongly linked to the
requirements of the Java 8 platform, which was problematic for
scala.js & friends.
Instead of ruling out SAM types that we can't compile to use
LambdaMetaFactory, expand those during compilation to anonymous
subclasses, instead of invokedynamic + LMF.
Also, self types rear their ugly heads again. Align `hasSelfType`
with the implementation suggested in `thisSym`'s docs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They both compile to INDY/MetaLambdaFactory, except when they
occur in a constructor call. (TODO: can we lift the ctor arg
expression to a method and avoid statically synthesizing
anonymous subclass altogether?)
Typers:
- no longer synthesize SAMs -- *adapt* a Function literal
to the expected (SAM/FunctionN) type
- Deal with polymorphic/existential sams (relevant tests:
pos/t8310, pos/t5099.scala, pos/t4869.scala) We know where
to find the result type, as all Function nodes have a
FunctionN-shaped type during erasure. (Including function
literals targeting a SAM type -- the sam type is tracked as
the *expected* type.)
Lift restriction on sam types being class types. It's enough
that they dealias to one, like regular instance creation
expressions.
Contexts:
- No longer need encl method hack for return in sam.
Erasure:
- erasure preserves SAM type for function nodes
- Normalize sam to erased function type during erasure,
otherwise we may box the function body from `$anonfun(args)`
to `{$anonfun(args); ()}` because the expected type for the
body is now `Object`, and thus `Unit` does not conform.
Delambdafy:
- must set static flag before calling createBoxingBridgeMethod
- Refactored `createBoxingBridgeMethod` to wrap my head around
boxing, reworked it to generalize from FunctionN's boxing
needs to arbitrary LMF targets.
Other refactorings: ThisReferringMethodsTraverser, TreeGen.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, concrete methods in traits were encoded with
"trait implementation classes".
- Such a trait would compile to two class files
- the trait interface, a Java interface, and
- the implementation class, containing "trait implementation methods"
- trait implementation methods are static methods has an explicit self
parameter.
- some methods don't require addition of an interface method, such as
private methods. Calls to these directly call the implementation method
- classes that mixin a trait install "trait forwarders", which implement
the abstract method in the interface by forwarding to the trait
implementation method.
The new encoding:
- no longer emits trait implementation classes or trait implementation
methods.
- instead, concrete methods are simply retained in the interface, as JVM 8
default interface methods (the JVM spec changes in
[JSR-335](http://download.oracle.com/otndocs/jcp/lambda-0_9_3-fr-eval-spec/index.html)
pave the way)
- use `invokespecial` to call private or particular super implementations
of a method (rather `invokestatic`)
- in cases when we `invokespecial` to a method in an indirect ancestor, we add
that ancestor redundantly as a direct parent. We are investigating alternatives
approaches here.
- we still emit trait fowrarders, although we are
[investigating](https://github.com/scala/scala-dev/issues/98) ways to only do
this when the JVM would be unable to resolve the correct method using its rules
for default method resolution.
Here's an example:
```
trait T {
println("T")
def m1 = m2
private def m2 = "m2"
}
trait U extends T {
println("T")
override def m1 = super[T].m1
}
class C extends U {
println("C")
def test = m1
}
```
The old and new encodings are displayed and diffed here: https://gist.github.com/retronym/f174d23f859f0e053580
Some notes in the implementation:
- No need to filter members from class decls at all in AddInterfaces
(although we do have to trigger side effecting info transformers)
- We can now emit an EnclosingMethod attribute for classes nested
in private trait methods
- Created a factory method for an AST shape that is used in
a number of places to symbolically bind to a particular
super method without needed to specify the qualifier of
the `Super` tree (which is too limiting, as it only allows
you to refer to direct parents.)
- I also found a similar tree shape created in Delambdafy,
that is better expressed with an existing tree creation
factory method, mkSuperInit.
|
|
|
|
|
|
| |
Added a deprecation warning for `-optimize`.
Later we'll also graduate `-Yopt` to `-opt`, probably for 2.12.0-M5.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/tools/nsc/backend/opt/ConstantOptimization.scala
src/compiler/scala/tools/nsc/transform/Constructors.scala
src/compiler/scala/tools/nsc/typechecker/Contexts.scala
src/scaladoc/scala/tools/nsc/doc/html/page/Template.scala
src/scaladoc/scala/tools/nsc/doc/html/resource/lib/jquery.layout.js
|
| |
| |
| |
| | |
The the word 'the' is often used twice. Fix that.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Language imports are preceding other imports
- Deleted empty file: InlineErasure
- Removed some unused private[parallel] methods in
scala/collection/parallel/package.scala
This removes hundreds of warnings when compiling with
"-Xlint -Ywarn-dead-code -Ywarn-unused -Ywarn-unused-import".
|
|\| |
|
| |
| |
| |
| |
| | |
It remains from the days of yore, when patterns survived this long
in the compiler.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using the "uncurry-erased" type (the one after the uncurry phase) can
lead to incorrect tree transformations. For example, compiling:
```
def foo(c: Ctx)(l: c.Tree): Unit = {
val l2: c.Tree = l
}
```
Results in the following AST:
```
def foo(c: Ctx, l: Ctx#Tree): Unit = {
val l$1: Ctx#Tree = l.asInstanceOf[Ctx#Tree]
val l2: c.Tree = l$1 // no, not really, it's not.
}
```
Of course, this is incorrect, since `l$1` has type `Ctx#Tree`, which is
not a subtype of `c.Tree`.
So what we need to do is to use the pre-uncurry type when creating
`l$1`, which is `c.Tree` and is correct. Now, there are two
additional problems:
1. when varargs and byname params are involved, the uncurry
transformation desugares these special cases to actual
typerefs, eg:
```
T* ~> Seq[T] (Scala-defined varargs)
T* ~> Array[T] (Java-defined varargs)
=>T ~> Function0[T] (by name params)
```
we use the DesugaredParameterType object (defined in
scala.reflect.internal.transform.UnCurry) to redo this desugaring
manually here
2. the type needs to be normalized, since `gen.mkCast` checks this
(no HK here, just aliases have to be expanded before handing the
type to `gen.mkAttributedCast`, which calls `gen.mkCast`)
|
| |
| |
| |
| |
| |
| |
| |
| | |
only trivial merge conflicts here.
not dealing with PR #4333 in this merge because there is a substantial
conflict there -- so that's why I stopped at
63daba33ae99471175e9d7b20792324615f5999b for now
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Uncurry seems more logical to me. Ideally, Erasure would erase
ConstantTypes, since they do not exist in bytecode.
In any case, doing this earlier, when we're rewriting method anyway,
simplifies constructors, which should be focussing on, well,
constructors (& fields).
|
|\|
| |
| |
| | |
merge/2.11.x-to-2.12.x-20152307
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A previous change disabled -Ydelambdafy:method for specialized
lambdas, as `DelambdafyTransformer` made no attempt to emit
the requisite machinery to avoid boxing.
This was loosened to allow them under `-target:jvm-1.8`, in the
knowledge that `indylambda` would do the right thing.
However, this wasn't quite right: indylambda is only supported
in `GenBCode`, so we should consider that setting as well.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Require Java 8 in ant build
- use -source 1.8 and -target 1.8 for javac
- Default scalac's -target to `jvm-1.8`, ignore and deprecate attempts
to use `jvm-1.{6.7}`
- Remove fragile javap-app test. The feature itself is slated for removal.
- Remove obsolete Java6 checkfile
- Adapt DCE tests
- Remove deprecated/redundant -target:jvm-1.6 from flags where the
intent was to trigger generation of stack map frames.
- Remove tests with -target:jvm-1.5 that tested without stack
map frames
- Ignore OpenJDK JVM warnings (via test/[files|scaladoc]/filters).
|
|
|
|
|
|
|
|
|
|
| |
Previously, the flag caused any elidable to be elided.
This commit simply sets -Xelide-below to ASSERTION + 1.
The flag is useful because there's no mnemonic for specifying
the magic constant as an option argument. `-Xelide-below ASSERTION`
means asserts are enabled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
scala> (x: Int) => {??? : Int}
res2: Int => Int = $$Lambda$1371/1961176822@6ed3ccb2
scala> res2(42)
scala.NotImplementedError: an implementation is missing
at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225)
at .$anonfun$1(<console>:8)
at $$Lambda$1371/1961176822.apply$mcII$sp(Unknown Source)
... 33 elided
scala> (x: Int, y: Long) => {??? : Int}
res4: (Int, Long) => Int = $$Lambda$1382/1796047085@6f8e8894
scala> res4(0, 0L)
scala.NotImplementedError: an implementation is missing
at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225)
at .$anonfun$1(<console>:8)
at $$Lambda$1382/1796047085.apply$mcIIJ$sp(Unknown Source)
... 33 elided
```
|
|\
| |
| | |
Disable -Ydelambdafy:method for specialized FunctionN
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Delambdafy phase generates its `FunctionN` subclasses after
the specialization phase. As such, `((x: Int) => x).apply(42)` incurs
boxing.
This commit falls back to the `-Ydelambdafy:inline` in this case.
This is done by running the specialization type map over the
type of the function, and seeing if anything changes. To make this
work robustly, we first need to ensure that the specialization info
transformer has processed all the function types.
This is not a fundamental limitation; we could in principle generate
the specialized code.
A followup change will use `-Ydelambdafy:method` as the basis for
invokedymnamic lambdas. As part of that stream of
work, we will synthesize specialization-aware lambdas, and remove
the fallback to `-Ydelambdafy:inline`.
I have updated some tests that intend to test the delambdafy transform
to avoid use of specialized function types.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Added `since` to deprecation statement
- Added unit to parameter list
- Removed usage of deprecated method polyType
- Replaced deprecated `debugwarn` with `devWarning`
- Changed switch statement to if else in order to remove a warning
- Switched implementation of `init` and `processOptions` to prevent
warning
- Replaced deprecated `Console.readLine` with `scala.io.StdIn.readLine`
- Replaced deprecated `startOrPoint` with `start`
- Replaced deprecated `tpe_=` with `setType`
- Replaced deprecated `typeCheck` with `typecheck`
- Replaced deprecated `CompilationUnit.warning` with `typer.context.warning`
- Replaced deprecated `scala.tools.nsc.util.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader`
- Replaced deprecated `scala.tools.ListOfNil` with `scala.reflect.internal.util.ListOfNil`
- Replaced deprecated `scala.tools.utils.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader`
- Replaced deprecated `emptyValDef` with `noSelfType`
- In `BoxesRunTime` removed unused method and commented out unused values. Did not delete to keep a reference to the values. If they are deleted people might wonder why `1` and `2` are not used.
- Replaced deprecated `scala.tools.nsc.util.AbstractFileClassLoader` with `scala.reflect.internal.util.AbstractFileClassLoader`
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Members of value classes are moved over to the companion object early.
This change ensures that closure classes nested in value classes
appear that way to Java reflection.
This commit also changes the EnclosingMethod attribute for classes
(and anonymous functions) nested in anonymous function bodies. Before,
the enclosing method was in some cases the function's apply method.
Not always though:
() => { class C ... val a = { class D ...} }
The class C used to be nested in the function's apply method, but not
D, because the value definition for a was lifted out of the apply.
After this commit, we uniformly set the enclosing method of classes
nested in function bodies to `null`. This is consistent with the
source-level view of the code.
Note that under delambdafy:method, closures never appear as enclosing
classes (this didn't change in this commit).
|
|
|
|
|
|
| |
doesn't leak uncatchable errors. Interestingly enough, the problem
only manifested itself for custom unapply methods, not for synthetic
ones generated for case classes.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code that generated the Java varargs forwarder was basing
things on the `ValDef-s` of the parameters of the source method.
But, their types refer to a type parameter skolems of the enclosing
method, which led to a type mismatch when typechecking the forwarder.
Instead, I've reworked the code to simply use the `DefDef`-s symbol's
info, which *doesn't* refer to skolems. This actually simplifies the
surrounding code somewhat; rather than repeated symbols in a map
we can just time travel the pre-uncurry method signatures to figure
out which params are releated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inline the forwarders from CompilationUnit, which should not affect behavior.
Since all forwarders lead to global.reporter, don't first navigate
to a compilation unit, only to then forward back to global.reporter.
The cleanup in the previous commits revealed a ton of confusion
regarding how to report an error.
This was a mechanical search/replace, which has low potential for messing
things up, since the list of available methods are disjoint between
`reporter` and `currentRun.reporting`. The changes involving `typer.context`
were done previously.
Essentially, there are three ways to report:
- via typer.context, so that reporting can be silenced (buffered)
- via global.currentRun.reporting, which summarizes (e.g., deprecation)
- via global.reporter, which is (mostly) stateless and straightforward.
Ideally, these should all just go through `global.currentRun.reporting`,
with the typing context changing that reporter to buffer where necessary.
After the refactor, these are the ways in which we report (outside of typer):
- reporter.comment
- reporter.echo
- reporter.error
- reporter.warning
- currentRun.reporting.deprecationWarning
- currentRun.reporting.incompleteHandled
- currentRun.reporting.incompleteInputError
- currentRun.reporting.inlinerWarning
- currentRun.reporting.uncheckedWarning
Before:
- c.cunit.error
- c.enclosingUnit.deprecationWarning
- context.unit.error
- context.unit.warning
- csymCompUnit.warning
- cunit.error
- cunit.warning
- currentClass.cunit.warning
- currentIClazz.cunit.inlinerWarning
- currentRun.currentUnit.error
- currentRun.reporting
- currentUnit.deprecationWarning
- currentUnit.error
- currentUnit.warning
- getContext.unit.warning
- getCurrentCUnit.error
- global.currentUnit.uncheckedWarning
- global.currentUnit.warning
- global.reporter
- icls.cunit.warning
- item.cunit.warning
- reporter.comment
- reporter.echo
- reporter.error
- reporter.warning
- reporting.deprecationWarning
- reporting.incompleteHandled
- reporting.incompleteInputError
- reporting.inlinerWarning
- reporting.uncheckedWarning
- typer.context.unit.warning
- unit.deprecationWarning
- unit.echo
- unit.error
- unit.incompleteHandled
- unit.incompleteInputError
- unit.uncheckedWarning
- unit.warning
- v1.cunit.warning
All these methods ended up calling a method on `global.reporter`
or on `global.currentRun.reporting` (their interfaces are disjoint).
Also clean up `TypeDiagnostics`: inline nearly-single-use private methods.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As @magarciaEPFL has done in his experimental optimizer [1], we can
avoid running into limitations of lambdalift (either `VerifyError`s,
ala SI-6666, or compiler crashes, such as this bug), by using the
old style of "inline" lambda translation when in a super- or self-
construtor call.
We might be able to get these working later on, but for now we
shouldn't block adoption of `-Ydelamndafy:method` for this corner
case.
[1] https://github.com/magarciaEPFL/scala/blob/GenRefactored99sZ/src/compiler/scala/tools/nsc/transform/UnCurry.scala#L227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There’s been a conflation of two distinct meanings of the word “local”
in the internal symbol API: the first meaning being “local to this”
(as in has the LOCAL flag set), the second meaning being “local to block”
(as in declared in a block, i.e. having owner being a term symbol).
Especially confusing is the fact that sym.isLocal isn’t the same as
sym.hasFlag(LOCAL), which has led to now fixed SI-6733.
This commit fixes the semantic mess by deprecating both Symbol.isLocal and
Symbol.hasLocalFlag (that we were forced to use, because Symbol.isLocal
had already been taken), and replacing them with Symbol.isLocalToThis
and Symbol.isLocalToBlock. Unfortunately, we can’t remove the deprecated
methods right away, because they are used in SBT, so I had to take small
steps.
|
|
|
|
|
| |
Only perform HashMap lookup of a tree until after checking more
cheaply if it refers to a symbol with by-name parameter type.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Super-accessors are generated as `DefDef`'s with `EmptyTree` as a
placeholder for the RHS. This is filled in later in `Mixin` in
`completeSuperAccessor`.
A change in `Uncurry` (SI-6443 / 493197f), however, converted this
to a `{ EmptyTree }`, which evaded the pattern match in mixin.
This commit adds a special case to the dependent method treatment
in Uncurry to avoid generating redundant blocks.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This emerges from a recent attempt to eliminate pattern matcher
related duplication and to bake the scalac-independent logic
out of it. I had in mind something a lot cleaner, but it was
a whole lot of work to get it here and I can take it no further.
Key file to admire is PatternExpander.scala, which should
provide a basis for some separation of concerns.
The bugs addressed are a CCE involving Tuple1 and an imprecise
warning regarding multiple pattern crushing.
Editorial: auto-tupling unapply results was a terrible idea which
should never have escaped from the crib. It is tantamount to
purposely throwing type safety down the toilet in the very place
where people need type safety the most. See SI-6111 and SI-6675 for
some other comments.
|
| | |
|