| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |\
| | |
| | | |
SI-9102: Reflect method invoke with mixed args
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Cover the second use case reported on the ML (ctors).
Improve formatting per the review. And it really does look
a lot better.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
A missing default branch when a method had value class
or by-name params caused other args to present as null
under reflective invocation.
|
| | |\ \
| | | |
| | | | |
SI-9219 Stream toString returns unexpected result
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Cursor was not advanced before appending the second element
when only the first two elements of the stream were known.
- When there is no cycle in the stream, the "scout" (and
"cursor") ends up pointing to a stream where tailDefined
is false. This means that cursor is either empty, or
cursor.tail is not yet evaluated. The former case is handled
properly, but in the latter case, one more element
(cursor.head) needs to be appended.
|
| | |\ \ \
| | | | |
| | | | | |
Resurrect a test for type inference
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This test was removed in ... when case class extension was disallowed.
But the intent of the test was actually to exercise a path through
type inference, described in `Infer#exprTypeArgs`.
When I remove that special case, the test still fails:
```
test/files/pos/jesper.scala:29: error: No implicit view available from Pair.Cons[Int,Pair.Cons[Boolean,Pair.End]] => Boolean.
val x2 : Boolean = p.find[Boolean] // Doesn't compile
^
one error found
```
This special case is important to understand when deciphering
the inference in this program:
```
object Test {
trait Cov[+A]
def cov[A](implicit ev: Cov[A]): A = ???
implicit def covImp[A]: Cov[A] = ???
trait Inv[A]
def inv[A](implicit ev: Inv[A]): A = ???
implicit def invImp[A]: Inv[A] = ???
trait Con[-A]
def con[A](implicit ev: Con[A]): A = ???
implicit def conImp[A]: Con[A] = ???
cov : String // (Test.this.cov[String](Test.this.covImp[Nothing]): String);
// (Test.this.cov[Nothing](Test.this.covImp[Nothing]): String) (or, without the special case in exprTypeArgs)
inv : String // (Test.this.inv[Nothing](Test.this.invImp[Nothing]): String);
con : String // (Test.this.con[Any](Test.this.conImp[Any]): String)
}
```
|
| | |\ \ \
| | | | |
| | | | | |
Inliner for GenBCode
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Method bodies that contain a super call cannot be inlined into other
classes. The same goes for methods containing calls to private
methods, but that was already ensured before by accessibility checks.
The last case of `invokespecial` instructions is constructor calls.
Those can be safely moved into different classes (as long as the
constructor is accessible at the new location).
Note that scalac never emits methods / constructors as private in
bytecode.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The inliner would incorrectly treat trait field accessors like
ordinary trait member methods and try to re-write invocations to the
corresponding static method in the implementation class. This rewrite
usually failed because no method was found in the impl class.
However, for lazy val fields, there exists a member in the impl class
with the same name, and the rewrite was performed. The result was that
every field access would execute the lazy initializer instead of
reading the field.
This commit checks the traitMethodWithStaticImplementation field of
the ScalaInlineInfo classfile attribute and puts an explicit
`safeToRewrite` flag to each call site in the call graph. This cleans
up the code in the inliner that deals with rewriting trait callsites.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Issue precise warnings when the inliner fails to inline or analyze a
callsite. Inline failures may have various causes, for example because
some class cannot be found on the classpath when building the call
graph. So we need to store problems that happen early in the optimizer
(when building the necessary data structures, call graph, ClassBTypes)
to be able to report them later in case the inliner accesses the
related data.
We use Either to store these warning messages. The commit introduces
an implicit class `RightBiasedEither` to make Either easier to use for
error propagation. This would be subsumed by a biased either in the
standard library (or could use a Validation).
The `info` of each ClassBType is now an Either. There are two cases
where the info is not available:
- The type info should be parsed from a classfile, but the class
cannot be found on the classpath
- SI-9111, the type of a Java source originating class symbol cannot
be completed
This means that the operations on ClassBType that query the info now
return an Either, too.
Each Callsite in the call graph now stores the source position of the
call instruction. Since the call graph is built after code generation,
we build a map from invocation nodes to positions during code gen and
query it when building the call graph.
The new inliner can report a large number of precise warnings when a
callsite cannot be inlined, or if the inlining metadata cannot be
computed precisely, for example due to a missing classfile.
The new -Yopt-warnings multi-choice option allows configuring inliner
warnings.
By default (no option provided), a one-line summary is issued in case
there were callsites annotated @inline that could not be inlined.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I observed cases (eg Scaladoc tests) where we end up with 17k+
ClassNodes, which makes 500 MB.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The self parameter type may be incompatible with the trait type.
trait T { self: S => def foo = 1 }
The $self parameter type of T$class.foo is S, which may be unrelated
to T. If we re-write a call to T.foo to T$class.foo, we need to cast
the receiver to S, otherwise we get a VerifyError.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In order to inline a final trait method, callsites of such methods are
first re-written from interface calls to static calls of the trait's
implementation class. Then inlining proceeds as ususal.
One problem that came up during development was that mixin methods are
added to class symbols only for classes being compiled, but not for
others. In order to inline a mixin method, we need the InlineInfo,
which so far was built using the class (and method) symbols. So we had
a problem with separate compilation.
Looking up the symbol from a given classfile name was already known to
be brittle (it's also one of the weak points of the current inliner),
so we changed the strategy. Now the InlineInfo for every class is
encoded in a new classfile attribute.
This classfile attribute is relatively small, because all strings it
references (class internal names, method names, method descriptors)
would exist anyway in the constant pool, so it just adds a few
references.
When building the InlineInfo for a class symbol, we only look at the
symbol properties for symbols being compiled in the current run. For
unpickled symbols, we build the InlineInfo by reading the classfile
attribute.
This change also adds delambdafy:method classes to currentRun.symSource.
Otherwise, currentRun.compiles(lambdaClass) is false.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The inliner forces some method symbols to complete that would not be
completed otherwise. This triggers SI-9111, in which the completer of
a valid Java method definition reports an error in mixed compilation.
The workaround disables error reporting while completing lazy method
and class symbols in the backend.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In mixed compilation, the bytecode of Java classes is not availalbe:
the Scala compiler does not produce any, and there are no classfiles
yet.
When inlining a (Scala defined) method that contains an invocation to
a Java method, we need the Java method's bytecode in order to check
whether that invocation can be transplanted to the new location
without causing an IllegalAccessError. If the bytecode cannot be
found, inlining won't be allowed.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `ByteCodeRepository.classNode(InternalName)` method now returns an
option. Concretely, in mixed compilation, the compiler does not create
a ClassNode for Java classes, and they may not exist on the classpath
either.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The current heuristics are simple: attempt to inline every method
annotated `@inline`. Cycles in the inline request graph are broken
in a determinisitc manner. Inlining is then performed starting at the
leaves of the inline request graph, i.e., with those callsites where
the target method has no callsites to inline.
This expansion strategy can make a method grow arbitrarily. We will
most likely have to add some thresholds and / or other measures to
prevent size issues.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Inlining decisions will be taken by analyzing the ASM bytecode. This
commit adds tools to build a call graph representation that can be
used for these decisions.
The call graph is currently built by considering method descriptors of
callsite instructions. It will become more precise by using data flow
analyses.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Note that JUnit creates a new instance of the test class for running
each test method. So the compiler instance is added to the companion.
However, the JVM would quickly run out of memory when running multiple
tests, as the compilers cannot be GCd. So we make it a `var`, and set
it to null when a class is done. For that we use JUnit's `@AfterClass`
which is required to be on a static method. Therefore we add a Java
class with such a static method that we can extend from Scala.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The method Inliner.inline clones the bytecode of a method and copies
the new instructions to the callsite with the necessary modifications.
See comments in the code.
More tests are added in a later commit which integrates the inliner
into the backend - tests are easier to write after that.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Some instructions would cause an IllegalAccessError if they are
inlined into a different class.
Based on Miguel's implementation in 6efc0528c6.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Usually, the compiler tries avoids creating a field in a subclass
for a constructor parameter that is known to be stored in a field
in one of its superclasses.
However, in the enclosed test `run/t9223.scala`, this mechanism
confuses `=> A` with `A`, which results in a runtime
`ClassCastException`.
This commit avoids using param aliases for by-name parameters.
I have also added a test for something close the opposite case, where
the subclass has a strict parameter and the superclass has a by-name
parameter. This was working correctly before this patch.
|
| | |\| |
| | |/
| |/| |
Emit the ScalaInlineInfo attribute under GenASM
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The goal of this commit is to allow the new inliner (in GenBCode,
coming soon) to inline methods generated by the GenASM backend of
2.11.6.
The ScalaInlineInfo attribute is added to every classfile generated
by GenASM. It contains metadata about the class and its methods that
will be used by the new inliner.
Storing this metadata to the classfile prevents the need to look up a
class symbol for a certain class file name, a process that is known to
be brittle due to name mangling. Also, some symbols are not exactly
the same when originating in a class being compiled or an unpickled
one. For example, method symbols for mixed-in members are only added
to classes being compiled.
The classfile attribute is relatively small, because all strings it
references (class internal names, method names, method descriptors)
would exist anyway in the constant pool. It just adds a few references
and bits for each method in the classfile.
Jar sizes before:
480142 scala-actors.jar
15531408 scala-compiler.jar
5543249 scala-library.jar
4663078 scala-reflect.jar
785953 scalap.jar
After:
490491 scala-actors.jar (102.1%)
15865500 scala-compiler.jar (102.1%)
5722504 scala-library.jar (103.2%)
4788370 scala-reflect.jar (102.7%)
805890 scalap.jar (102.5%)
|
| | |\ \
| | | |
| | | | |
Merge 2.10.x to 2.11.x
|
| | | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/library/scala/concurrent/Promise.scala
test/files/jvm/future-spec/PromiseTests.scala
|
| | | | |\ \
| | | | | |
| | | | | | |
SI-8689 Avoid internal error in Promise after sequence of completions
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Calling `completeWith` when the `DefaultPromise` is already completed,
leads to callbacks not being properly executed.
This happened because `Future.InternalCallbackExecutor` extends
`BatchingExecutor`[1] which assumes `unbatchedExecute` to be async,
when in this case it is sync, and if there is an exception thrown
by executing the batch, it creates a new batch with the remaining
items from the current batch and submits that to `unbatchedExecute`
and then rethrows, but if you have a sync `unbatchedExecute`, it will
fail since it is not reentrant, as witnessed by the failed `require`
as reported in this issue.
This commit avoids problem by delegating `completeWith` to
`tryComplete`, which has the effect of using `onComplete` +
`tryComplete` i.s.o. `complete`, which means that when it fails
(because of a benign race condition between completers) it won't
throw an exception.
It has been tested by the minimized reproducer.
[1] Actually, in the 2.10.x branch where this patch is starting out,
"The BatchingExecutor trait had to be inlined into
InternalCallbackExecutor for binary compatibility.". This comment
will be more literally correct in the context of 2.11.x and beyond
|
| | | | |/ / |
|
| | | | |\ \
| | | | | |
| | | | | | |
[backport] SI-7756 Uncripple refchecks in case bodies
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In 65340ed4ad2e, parts of RefChecks were disabled when
we traversed into the results of the new pattern matcher.
Similar logic existed for the old pattern matcher, but in
that case the Match / CaseDef nodes still existed in the tree.
The new approach was too broad: important checks no longer
scrutinized the body of cases.
This commit turns the checks back on when it finds the remnants
of a case body, which appears as an application to a label def.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
Cherry pick of 3df1d77fc984b976efa68098206e801cf3b83a9e
|
| | | | |\ \ \
| | | | | | |
| | | | | | | |
[backport] SI-7470 implements fundep materialization
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
To quote gkossakowski:
Thinking about it more, could we hide this behind 'Y' flag instead?
We have lesser obligation to keep around Y flags and this is something
we should remove from 2.11/2.12.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Backports 21a8c6c from the 2.11.x branch under -Xfundep-materialization
as per Miles Sabin's request. Thanks Miles!
|
| | | | |\ \ \ \
| | | | | | | |
| | | | | | | | |
[backport] transformers no longer ignore UnApply.fun
|
| | | | | |/ / /
| | | | | | |
| | | | | | |
| | | | | | | |
Backports 7122560063 and 4133eb8454 from the 2.11.x branch
|
| | | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Initial implementation of pluginsEnterStats was incorrect, because I got
the foldLeft wrong, making it perpetuate the initial value of stats.
This worked fine if zero or one macro plugins were active at a time,
but broke down if there were multiple of such plugins (concretely,
I discovered this issue when trying to marry macro paradise with scalahost).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Added `.seq` in two essential places so that a parallel collection passed as an argument won't mess up side-effecting sequential computations in `List.flatMap` and `GenericTraversableTemplate.transpose` (thanks to retronym for finding the danger spots).
Tests that `.seq` is called by constructing a `GenSeq` whose `.seq` disagrees with anything non-`.seq` (idea & working implementation from retronym).
Also updates the `.seq` test for `Vector#++` to use the new more efficient method.
|
| | |\ \ \ \ \
| | |/ / / /
| |/| | | | |
SI-8801 Another test for fixed exponential-time compilation
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Turns out that SI-9157 was a duplicate of SI-8801. This commit
adds Paul's test, whose compile time is now back in the troposphere.
% time qscalac test/files/pos/t8801.scala
real 0m1.294s
user 0m3.978s
sys 0m0.240s
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9153 More complete and stable results for completions
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The checkfile of the tests added in the last commit offered
a type member from `RichInt` in the completions for the type
`Int`. However, only term members can be extension methods;
type members cannot.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Three items of background are needed to understand this bug.
1. When typechecking an application like `qual.m({stats; expr})`, the
argument is typechecked using the formal parameter type of `m` as the
expected type. If this fails with a type error located within in
`expr`, the typer instead re-typechecks under `ContextMode.ReTyping`
without an expected type, and then searches for an implicit adaptation
to enable `view(qual).m(args)`. Under this mode, `Typer#typed1`
clears the type of incoming trees.
2. The presentation compiler performs targetted operations like
type completions by:
- typechecking the enclosing tree, registering all typechecker
`Context`s created in the process (`registerContext`)
- finding the smallest enclosing `Context` around the target
position (`doLocateContext`)
- Using this context to perform implicit search, which can
contribute members to the completion. (`applicableViews` within
`interactive.Global#typeMembers`)
3. When verifiying whether or not a candidate implicit is applicable
as a view from `F => T`, implicit search typechecks a dummy call
of the form `q"candiate(${Ident("<argument>").setType(typeOf[F])})".
Now, picture yourself at the nexus of these three storms.
In the enclosed test case, we search for completions at:
x + 1.<caret>
1. Because the code is incomplete, the application of `Int#+`
doesn't typecheck, and the typer also tries to adapt `x` to a
method applicable to the re-typechecked argument.
2. This process registers a context with `retypechecking` set to
true. (If multiple contexts at the same position are registered,
the last one wins.)
3. Implicit search uses this context to typecheck
`Predef.Ensuring(<argument>.setType(Int))`, but the argument
is promptly stripped of its type and retypechecking fails
as there is no definition named `<argument>` in scope.
As such, we missed out on extension methods, like `ensuring` in the
list of completions.
This commit changes the presentation compiler to turn off retyping
mode in the context before starting to work with it. (Are the other
modes that might cause similar bugs?)
Once I made that change, I noticed that the results the enclosed test
was not stable. I tracked this down to the use of a `HashMap` to
carry the applicable implicit views, together with the way that
the presentation compiler removes duplicates. This commit
switched to a `LinkedHashMap`.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8917 collection.mutable.BitSet's &= operator doesn't clear end
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | | |
Made &= run to the end of its own bitset, ignoring the size of what it's &-ing with (which is exactly what you want for &=).
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fix SI-7943 -- make `TrieMap.getOrElseUpdate` atomic.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Override `getOrElseUpdate` method in `TrieMap`.
The signature and contract of this method corresponds closely to the
`computeIfAbsent` from `java.util.concurrent.ConcurrentMap`.
Eventually, `computeIfAbsent` should be added to
`scala.collection.concurrent.Map`.
Add tests.
Review by @Ichoran
|
