| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The byte value of a BIPUSH instruction and the (byte1 << 8) | byte2
value of a SIPUSH instruction are signed, see [1] and [2].
Similar for the increment value of IINC [3].
[1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.bipush
[2] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.sipush
[3] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.iinc
|
|\ \ \
| | | |
| | | | |
backports from 2.12.x
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Similar to the new JAVA_ANNOTATION flag, be more explicit about flags
for java entities.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Scala classfile and java source parsers make Java annotation
classes (which are actually interfaces at the classfile level) look
like Scala annotation classes:
- the INTERFACE / ABSTRACT flags are not added
- scala.annotation.Annotation is added as superclass
- scala.annotation.ClassfileAnnotation is added as interface
This makes type-checking @Annot uniform, whether it is defined in Java
or Scala.
This is a hack that leads to various bugs (SI-9393, SI-9400). Instead
the type-checking should be special-cased for Java annotations.
This commit fixes SI-9393 and a part of SI-9400, but it's still easy
to generate invalid classfiles. Restores the assertions that were
disabled in #4621. I'd like to leave these assertions in: they
are valuable and helped uncovering the issue being fixed here.
A new flag JAVA_ANNOTATION is introduced for Java annotation
ClassSymbols, similar to the existing ENUM flag. When building
ClassBTypes for Java annotations, the flags, superclass and interfaces
are recovered to represent the situation in the classfile.
Cleans up and documents the flags space in the area of "late" and
"anti" flags.
The test for SI-9393 is extended to test both the classfile and the
java source parser.
|
| | | |
| | | |
| | | |
| | | | |
Fixes the stability regression introduced by #4619.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A macro in shapeless was generating a tree of the form:
```
{
class C#2
new C#2
}.setType(C#1)
```
This happened due to an error in the macro; it used untypecheck
to try to fix the owner-chain consistency problem, but kept a
reference to the previous version of the block-local class symbol
`C` and used this in the resulting tree.
This commit detects the particular situation we encountered, and
avoids the crash by not creating the `NestedInfo` for the
`BType` corresponding to `C#1`. The code comment discusses why I
think this is safe, and suggests a refactoring that would mean
we only ever try to construct `NestedInfo` when we are going to
need them.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
These cause a crash in the build of Play. We should try to bring
these back once we have suitable annotation awareness. Perhaps
they should only be `devWarning`-s, though.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Refactor and clean up the ClosureOptimzier. The goal of this change
is to run the ProdCons analyzer only once per method, instead of
once per closure instantiation.
Bootstrapping scala with `-Yopt-inline-heuristics:everything` revealed
that ProdCons can take a very long time on large methods, for example
```
[quick.compiler] scala/tools/nsc/backend/jvm/BCodeBodyBuilder$PlainBodyBuilder#genArithmeticOp - analysis: 1 spans, 17755ms
[quick.compiler] scala/tools/nsc/typechecker/SuperAccessors$SuperAccTransformer#transform - analysis: 1 spans, 28024ms
[quick.compiler] scala/tools/nsc/backend/jvm/BCodeBodyBuilder$PlainBodyBuilder#genInvokeDynamicLambda - analysis: 1 spans, 22100ms
```
With this change and enough time and space (-Xmx6000m), bootstrapping
scala succeeds in this test mode.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As with regular `Apply`-s, we should compute the generated type
based on the function's type, rather than the expected type.
In the test case, the expected type was void. Now, we correctly
use the generated type of `scala/Function1`, which is enough
to generate a subsequent POP instruction.
The tree shape involved was:
```
arg0 = {
{
$anonfun()
};
scala.runtime.BoxedUnit.UNIT
}
```
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Introduces an extractor `LMFInvokeDynamic` that matches InvokeDynamic
instructions that are LambdaMetaFactory calls.
The case class `LambdaMetaFactoryCall` holds such an InvokeDynamic
instruction. It also holds the bootstrap arguments (samMethodType,
implMethod, instantiatedMethodType) so that they can be accessed
without casting the indy.bsmArgs.
The `closureInstantiations` map in the call graph now stores
ClosureInstantiation objects instead of a tuple.
This simplifies some code and gets rid of a few casts.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implements the necessary tests to check if a method with an
InvokeDynamic instruction can be inlined into a destination class.
Only InvokeDynamic instructions with LambdaMetaFactory as bootstrap
methods can be inlined. The accessibility checks cannot be implemented
generically, because it depends on what the bootstrap method is doing.
In particular, the bootstrap method receives a Lookup object as
argument which can be used to access private methods of the class
where the InvokeDynamic method is located.
A comment in the inliner explains the details.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When there are multiple closure allocations and invocations in the
same method, ensure that the callsites are re-written to the body
methods in a consistent order. Otherwsie the bytecode is not stable
(the local variable indices depend on the order in which the calls
are re-written)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add support in scalap to parse new constant pool entries
- MethodHandle
- MethodType
- InvokeDynamic
Spec: https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Generate the invocation to LambdaDeserializer.deserializeLambda by
loading the static MODULE$ field instead of calling the static method
in the mirror class.
This is more scala-y. Also, mirror classes don't have an InlineInfo
classfile attribute, so the inliner would yield a warning about
the mirror class callsite.
Also skip the stack map frame instruction - frames are computed by
the ams classfile writer.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When an instruction is its own producer or consumer, the
`initialProducer` / `ultimateConsumer` methods would loop.
While loops or @tailrec annotated methods can generate such bytecode.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the closure body method has return type Nothing$, add an `ATHROW`
instruction after the callsite. This is required for computing stack
map frames, as explained in a comment in BCodeBodyBuilder.adapt.
Similar for closure bodies with return type Null$.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
According to the spec [1] the superclass of an interface is always
Object.
Restores the tests that were moved to pending in bf951ec1,
fixex part of SI-9374.
[1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`javaBinaryName` returns the internal name of a class.
Also used in BTypesFromsymbols.classBTypeFromSymbol.
Weirdly, this was discovered due to a bizarre osgi bnd error:
```
[bnd] # addAll '/Users/luc/scala/scala/build/pack/lib/scala-library.jar' with :,
[bnd] # addAll '/Users/luc/scala/scala/build/osgi/scala-library.bnd' with ,
[bnd] 1 ERRORS
[bnd] The default package '.' is not permitted by the Import-Package syntax.
[bnd] This can be caused by compile errors in Eclipse because Eclipse creates
[bnd] valid class files regardless of compile errors.
[bnd] The following package(s) import from the default package [scala.collection.generic, scala.sys.process, scala.collection.parallel.mutable, scala.util, scala.collection.parallel.immutable, scala.reflect, scala.concurrent.impl, scala.util.hashing, scala.collection.parallel, scala.collection.convert, scala.io, scala, scala.collection.concurrent, scala.util.control, scala.beans, scala.concurrent.duration, scala.collection, scala.runtime, scala.math, scala.collection.mutable, scala.concurrent, scala.sys, scala.collection.immutable, scala.ref, scala.util.matching]
[bnd] /Users/luc/scala/scala/build/osgi/scala-library.bnd: bnd failed
```
Lukas diagnosed it as a problem of the generated `$deserializeLambda$` function:
One example is `scala/App$class`. Its bytecode contains this:
```
private static synthetic $deserializeLambda$(Ljava/lang/invoke/SerializedLambda;)Ljava/lang/Object;
GETSTATIC scala$divApp$class.$deserializeLambdaCache$ : Ljava/util/Map;
[...]
```
so it's a static field read of a top-level class.
`$div` should obviously be `/` (which this commit rectifies)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Java parser should not set the `DEFERRED` flag for
default methods or static methods in interfaces.
Their bytecode doesn't have it either.
Also tightens parsing of Java abstract methods to
disallow a method body.
Here's the log of how Lukas diagnosed this:
```
quick.bin:
...
BUILD FAILED
/Users/luc/scala/scala/build.xml:69: The following error occurred while executing this line:
...
/Users/luc/scala/scala/build-ant-macros.xml:350: Could not create type mk-bin due to
java.lang.BootstrapMethodError: call site initialization exception
at java.lang.invoke.CallSite.makeSite(CallSite.java:341)
at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
at scala.sys.BooleanProp$.keyExists(BooleanProp.scala:72)
at scala.sys.SystemProperties$.bool(SystemProperties.scala:78)
at scala.sys.SystemProperties$.noTraceSupression$lzycompute(SystemProperties.scala:89)
at scala.sys.SystemProperties$.noTraceSupression(SystemProperties.scala:89)
at scala.util.control.NoStackTrace$.<init>(NoStackTrace.scala:31)
at scala.util.control.NoStackTrace$.<clinit>(NoStackTrace.scala)
at scala.util.control.NoStackTrace$class.fillInStackTrace(NoStackTrace.scala:22)
at scala.util.control.BreakControl.fillInStackTrace(Breaks.scala:94)
at java.lang.Throwable.<init>(Throwable.java:250)
at scala.util.control.BreakControl.<init>(Breaks.scala:94)
at scala.util.control.Breaks.<init>(Breaks.scala:29)
at scala.collection.Traversable$.<init>(Traversable.scala:95)
at scala.collection.Traversable$.<clinit>(Traversable.scala)
at scala.package$.<init>(package.scala:40)
at scala.package$.<clinit>(package.scala)
at scala.Predef$.<init>(Predef.scala:89)
at scala.Predef$.<clinit>(Predef.scala)
at scala.tools.ant.ScalaTool.<init>(ScalaTool.scala:58)
[...]
Caused by: java.lang.invoke.LambdaConversionException:
Incorrect number of parameters for static method invokeStatic
scala.sys.BooleanProp$.scala$sys$BooleanProp$$$anonfun$2$adapted:(String)Object;
0 captured parameters, 0 functional interface method parameters, 1 implementation parameters
at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:193)
at java.lang.invoke.LambdaMetafactory.altMetafactory(LambdaMetafactory.java:473)
at java.lang.invoke.CallSite.makeSite(CallSite.java:325)
```
[source code](https://github.com/scala/scala/blob/2.11.x/src/library/scala/sys/BooleanProp.scala#L72):
```
s => s == "" || s.equalsIgnoreCase("true")
```
bytecode:
```
INVOKEDYNAMIC $init$()Lscala/compat/java8/JFunction1; [
// handle kind 0x6 : INVOKESTATIC
java/lang/invoke/LambdaMetafactory.altMetafactory(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
// arguments:
()V,
// handle kind 0x6 : INVOKESTATIC
scala/sys/BooleanProp$.scala$sys$BooleanProp$$$anonfun$2$adapted(Ljava/lang/String;)Ljava/lang/Object;,
(Ljava/lang/String;)Ljava/lang/Object;,
3,
1,
Lscala/Serializable;.class,
0
]
CHECKCAST scala/Function1
```
The mistake seems to be that the Scala compiler incorrectly selects `$init$`
([which is a default method](https://github.com/scala/scala/blob/640ffe7fceb5d573b2c12a7c7da09bfd751036a0/src/library/scala/compat/java8/JFunction1.java#L10))
as the abstract method of `JFunction1`, whereas it should be `apply` (inherited from `Function1`).
Since we're doing mixed compilation, this is almost certainly a problem of the Java parser.
|
| | | |
| | | |
| | | |
| | | | |
It was fixed in GenASM in 44807a7852.
|
|\ \ \ \
| |/ / /
|/| | | |
Ignore OpenJDK warnings in partest filters
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When running a 2.11.x validation on JDK 8, there are OpenJDK
warnings that fail tests. Backports a part of 8d2d3c70 to 2.11.x.
The missing filter causes merge commits to fail in PRs that merge
2.11 to 2.12, e.g., https://github.com/scala/scala/pull/4655.
In the future we probably want to trigger an integration build for
merge commits, but this doesn't happen yet AFAICT.
|
|\ \ \
| |/ /
|/| | |
bump copyright year to 2015
|
| | |
| | |
| | |
| | |
| | | |
(just hitting the highlights here, not worrying yet about bumping the
dates in every modified source file)
|
|\ \ \
| | | |
| | | | |
SI-8502 create PackageClass instead of Class symbol stubs for pkgs
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
https://github.com/scala/scala/pull/4111 creates a stub type symbol
for missing packages, deferring (or avoiding) a crash if a package
is missing.
The symbol created was a ClassSymbol, which could lead to an assertion
failure in flattten:
case TypeRef(pre, sym, args) if isFlattenablePrefix(pre) =>
assert(args.isEmpty && sym.enclosingTopLevelClass != NoSymbol, sym.ownerChain)
`pre` is the stub ClassSymbol, so `isFlattenablePrefix` is true (but
it should be false). The assertion then fails because the enclosing
class of a top-level class defined in a missing package is NoSymbol.
This failed only with GenBCode, which traverses more of the symbol
graph while building ClassBTypes: it looks collects the nested classes
of `Outer` into a `NestedInfo`.
|
|\ \ \
| | | |
| | | | |
Fix 23 typos (t-v)
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | | |
Fix 6 typos (w-z)
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | | |
Fix typo in val name
|
| |/ / |
|
|\ \ \
| | | |
| | | | |
Improve some names (t-v)
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | | |
SI-9409 Scaladoc: remove link to nonexistent diagram doc
|
| | |/
| |/| |
|
|\ \ \
| |/ /
|/| | |
SI-9406 fix doc for Range.takeRight
|
|/ / |
|
|\ \
| | |
| | | |
SI-9370 Xplugin scans plugin path for descriptor
|
| | |
| | |
| | |
| | |
| | | |
Keep on scanning if the first entry doesn't yield
a plugin.xml descriptor.
|
|\ \ \
| | | |
| | | | |
Update scaladoc for Any.scala#equals()
|
| | |/
| |/|
| | | |
The transitive requirement for `Any` shouldn't mention `AnyRef`
|
|\ \ \
| | | |
| | | | |
SI-9401 Avoid SOE with array + missing classtag
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The implicit classtags required by the Array constructor are not
expressed in the type signature of its constructor, and instead
are summoned by a special case in the typechecker.
This special case entails replacing the `new Array` tree with
`implicitly[T].newArray(size)`, handled in `ArrayInstantiation`.
This tree is recursively typechecked.
However, if the implicit materialization/search fails, an error
is issued to the current reporter and the original tree is marked
with an error type. As above, this is recursively typechecked.
In the normal course of affairs, the recursive typecheck of the
erroneous tree would be a noop (the tree already has a type!).
However, if we are both in silent mode (in which errors are buffered)
and in retyping mode (in which the typer clears the type and symbols
of trees), we were getting into an cycle.
In the enclosed test, retyping mode was trying to recover
from:
Resetting.this.gencastarray_=(new Array[T](0).<ERROR>)
By inserting a suitable a view:
implicitly[Resetting => { def gencastarray_=(AT)}](
Resetting.this
).gencastarray_=(new Array[T](0))
Where AT is the type found by retypechecking the argument.
It is during the argument retypechecking that we fell into cycle.
Crazily enough, in 2.11.0, the ensuing `StackOverflowError` was
being caught and treated as a failure. We would then back out of
the retyping mode, and issue the error from the the very first attempt
at the implicit search.
This fragile state of affairs was disrupted by a refactoring to
the error reporting system in 725c5c9, after which the SOE crashed
the compiler.
This commit avoids recursively typechecking error typed trees.
|
|\ \ \ \
| |/ / /
|/| | | |
SI-8744 fix version.number in scaladoc.properties
|
| |/ /
| | |
| | |
| | | |
the fix is as suggested by Adriaan in the ticket
|
|\ \ \
| | | |
| | | | |
use newer Redcarpet to build spec
|
| |/ /
| | |
| | |
| | |
| | | |
now that https://github.com/vmg/redcarpet/issues/494 is fixed
we don't need to stay pinned to an outdated version anymore
|