| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
I imagine these date back to old Subversion days and are probably the
result of inadvertent commits from Windows users with vcs client
configs.
having the bit set isn't really harmful most of the time,
but it's just not right, and it makes the files stand out in directory
listings for no reason
|
|\
| |
| | |
SI-9450 Fix triple quoted strings in REPL :power mode
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some extra synthetic code generated under this mode failed to escape
input before adding it to a literal string. It used to get away with
this most of the time by triple quoting the literal.
This commit reuses Scala string escaping logic buried in `Constant`
to do this properly. Actually, the proper approach would be to build
the synthetic code with trees and quasiquotes, and avoid the mess
of stringly-genererated code.
I threw in some defensive hygiene for the reference to `Nil` while
I was in the neighbourhood.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
toSet needs to rebuild some child classes, but not others, as toSet is
allowed to widen element types (which the invariant Set normally cannot do),
and some sets rely upon their invariance. Thus, sets that rely upon their
invariance now rebuild themselves into a generic set upon toSet, while those
that do not just sit there.
Note: there was a similar patch previously that fixed the same problem, but
this is a reimplementation to circumvent license issues.
Note: the newBuilder method was benchmarked as (surprisingly!) the most
efficient way to create small sets, so it is used where sets may need to
be rebuild.
|
| |
|
| |
|
|\
| |
| | |
SI-1931 Hide Predef.any2stringadd in REPL
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
User imports that reference Predef are relocated to the top of
the wrapping template so that they can hide implicits defined
in Predef.
Only one import from Predef is retained for special treatment.
This is simple and sane. The test shows that `import Predef._`
restores Predef implicits even if a user-defined term would
normally be in scope.
A smart `:import` command to turn off or quarantine imports explicitly
would allow fine-grained control.
|
|\ \
| | |
| | | |
SI-9425 Leave Companion.apply if constructor is less accessible
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Calls to synthetic case class apply methods are inlined to the
underlying constructor invocation in refchecks.
However, this can lead to accessibility errors if the constructor
is private.
This commit ensures that the constructor is at least as accessible
as the apply method before performing this tranform.
I've manually checked that other the optimization still works in other
cases:
scala> class CaseApply { Some(42) }
defined class CaseApply
scala> :javap -c CaseApply
Compiled from "<console>"
public class CaseApply {
public CaseApply();
Code:
0: aload_0
1: invokespecial #9 // Method java/lang/Object."<init>":()V
4: new #11 // class scala/Some
7: dup
8: bipush 42
10: invokestatic #17 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
13: invokespecial #20 // Method scala/Some."<init>":(Ljava/lang/Object;)V
16: pop
17: return
}
|
|\ \ \
| |/ /
|/| | |
SI-9422 Fix incorrect constant propagation
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ConstantOptimization phase uses abstract interpretation
to track what is known about values, and then to use this information
to optimize away tests with a statically known result.
Constant propagation was added under -optimize in Scala 2.11.0-M3, in
PR #2214.
For example, we might know that a variable must hold one of a set
of values (`Possible`). Or, we could track that it must *not*
be of of a set of value (`Impossible`).
The test case in the bug report was enough to create comparison:
v1 == v2 // where V1 = Possible(Set(true, false))
// V2 = Possible(Set(true, false))
This test was considered to be always true, due to a bug in
`Possible#mightNotEqual`. The only time we can be sure that
`Possible(p1) mightNotEquals Possible(p2)` is if
`p1` and `p2` are the same singleton set. This commit changes
this method to implement this logic.
The starting assumption for all values is currently
`Impossible(Set())`, although it would also be reasonable to represent
an unknown boolean variable as `Possible(Set(true, false))`, given
the finite and small domain.
I tried to change the starting assumption for boolean locals in
exactly this manner, and that brings the bug into sharp focus.
Under this patch:
https://github.com/retronym/scala/commit/e564fe522d
This code:
def test(a: Boolean, b: Boolean) = a == b
Compiles to:
public boolean test(boolean, boolean);
Code:
0: iconst_1
1: ireturn
Note: the enclosed test case does not list `-optimize` in a `.flags`
file, I'm relying on that being passed in by the validation build.
I've tested locally with that option, though.
|
|\ \ \
| | | |
| | | | |
ScalaDoc fixes for library and library-aux
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
SI-9365 Don't null out dependencies of transient lazy vals
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As per Iulian's analysis:
> When lazy vals are transient, the optimization in SI-720 is invalid,
> leading to NPEs.
These NPEs appear when recomputing the lazy val when deserializaing
the object.
This commit disables the field nulling if the lazy val is marked
transient.
The post-mixin tree in the enclosed test changes as follows:
```
--- sandbox/old.log 2015-07-27 15:48:03.000000000 +1000
+++ sandbox/new.log 2015-07-27 15:47:56.000000000 +1000
@@ -1,61 +1,54 @@
[[syntax trees at end of mixin]] // t9365.scala
package <empty> {
class Test extends Object with Serializable {
@transient @volatile private[this] var bitmap$trans$0: Boolean = false;
private def foo$lzycompute(): Object = {
{
Test.this.synchronized({
if (Test.this.bitmap$trans$0.unary_!())
{
Test.this.foo = Test.this.x.apply();
Test.this.bitmap$trans$0 = true;
()
};
scala.runtime.BoxedUnit.UNIT
});
- Test.this.x = null
+ ()
};
Test.this.foo
};
```
In addition to the test from the ticket, I've added a reflection
based test that directly tests the nulling. This complements the
test added in 449f2a7473, the fix for SI-720, which passes by
virtue of not exhausting the heap.
|
|\ \ \
| | | |
| | | | |
SI-9403 fix ICodeReader for negative BIPUSH / SIPUSH values
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
}
```
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
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)
|
| | |/
| |/| |
|
|\ \ \
| |_|/
|/| | |
Improve some names (t-v)
|
| |/ |
|
|\ \
| | |
| | | |
SI-9370 Xplugin scans plugin path for descriptor
|
| | |
| | |
| | |
| | |
| | | |
Keep on scanning if the first entry doesn't yield
a plugin.xml descriptor.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
|\ \
| | |
| | | |
Fix 27 typos (p-r)
|
| | | |
|
|\ \ \
| |/ /
|/| | |
SI-9206 REPL custom bits
|
| | |
| | |
| | |
| | |
| | | |
The welcome message defaults to a sober header followed by
one line of instructions.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Everyone knows that a `help` command will result in `more information`.
This commit moves the version string to the second line and adds some
verve to the welcome.
If anyone can't live without the old banner, they are now able to
configure it explicitly, so there is still no blood on our hands.
```
$ scala
Welcome to Scala version 2.11.6 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_40).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :quit
$ skala
Welcome to Scala!
version 2.11.7-20150623-155244-eab44dd092 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_40).
Type in expressions for evaluation. Or try :help.
scala> :quit
```
REPL tests now lop off the actual length of the welcome header; or, if
necessary, remove the version number from a header embedded in output.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Anyone who doesn't understand why result printing was turned
off after they entered `:silent` mode will start the REPL
with `-Dscala.repl.debug` and be enlightened.
For infotainment purposes, the verbose message is also emitted
under info mode.
|
|\ \ \
| |_|/
|/| | |
SI-6895 Test cases to explain the limitations in tcpoly inference
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since beadafa2, we've ended up with nutty error messages for
type errors involving aliases that target types in `java.lang` and
`scala` packages. I think the intent of that change was to force
the error messages to qualify types like `String` when needed, but
to leave them unqualified by default.
However, this led to this flat out wrong message in the enclosed test.
found : B
required: C.this.java.lang.B
(which expands to) String
I've changed the heuristic slightly limit this code to aliases
that are eponymous with their targets. Still feels pretty kludgy, but
we can at least book a little progress.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When printing types in error messages, we attempt to disambiguate
symbol names by qualifying them in various ways.
Type paramters symbols are qualified by adding `(in someMethod)`.
However, the type errors generated by higher kinded subtyping
can contain clones of type parameter symbols, as creater in
`isPolySubType`. The disambiguation tries fruitlessly to distinguish
them but ended up adding the same suffix to both names repeatedly.
```
found : [F[_]]Foo[[X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]Bar[F,X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]]
required: Foo[[X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]Bar[[X]Or[String,X],X(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)(in type L)]]
```
This commit limits the post qualification of type parameter symbols
to a single attempt to limit the damage. An alternative might
be to mark a clone (we could determine its status by checking whether
it is a type parameter of its owner.) But I'm not sure how to present
this information in a comphrenensible way, so for now I'm limiting
my ambitions to stopping the stutter.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I've determined that the failure in this bug report boils down
to SI-2712. Submitting my working as neg tests for posterity.
The type error disabmiguator develops a serious stutter with this
example. I'll fix that in the following commit.
|
|\ \ \
| | | |
| | | | |
GenBCode: fix incrementatal compilation by mimicing GenASM
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The incremental compiler in SBT uses an implementation detail
of the compiler backend to enumerate the classes that are actually
written to disk.
This commit mimics this in GenBCode by populating `Run#icode` with
an `IClass` for each `ClassDef` processed.
We should revisit this by creating a dedicated API for this purpose
and migrating SBT to use that. We should also revisit this code
as we implement closure elimination in the GenBCode; this commit
assumes that all `ClassDef`s that enter the backend will generate
classfile products.
The enclosed test is extracted from the incrementatl compiler.
I've also manually integration tested this with SBT:
https://gist.github.com/retronym/fabf6f92787ea9c1ce67
|
|\ \ \ \
| | | | |
| | | | | |
Improved message for missing argument list
|