| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is Paul's test demonstrating that Javac errors are
correctly transcribed in the test transcript.
A gratuitous Scala class is added to a later round to
show that the test halts after the first error.
The runner must supply absolute paths to javac so that
absolute paths are reported in errors and stripped away
by partest.
The check file is differentiated for Java 6 and 7,
and partest's runner will now post-process the
`diff log check` to strip the diff which does not apply.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Paulptest includes color and simplified test scarfing.
Scalap tests are moved to the conventional name and location.
Testicolor missed out on Josh Suereth's tweak to sort the files in
a compilation round. Restore sortiness to test sources.
Testicolor is due to one of Paul's branches on a timeline
that apparently did not include the destruction of planet
Earth and its colonies by the Xindi.
Thanks also to Szabolcs Berecz for his merge effort. Merging
is thankless work, but not as thankless as merging in a
timeline that actually does terminate in the destruction of
your home world and Enterprise.
Archer had a supremely difficult choice: rescue humanity or
live out his retirement with T'Pol waiting on him hand and
foot? I'm sure I don't know how I'd choose.
|
| |\
| |
| | |
SI-7110 Warn about naked try without catch/finally
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before, this was allowed:
scala> try ( 1 / 0 )
java.lang.ArithmeticException: / by zero
But since the advent of util.Try, the subtle difference to the
following seems dangerous:
scala> import util.Try
import util.Try
scala> Try ( 1 / 0 )
res4: scala.util.Try[Int] = Failure(java.lang.ArithmeticException: / by zero)
Discussion: https://groups.google.com/d/topic/scala-language/fy2vXD_3fF8/discussion
There was some concern that this curtails a handy, temporary
way to remove the exception handlers from some code. But after
thinking about this, I contend that:
a) those people can easily stomach the warning temporarily
(modulo, of course, those with -Xfatal-warnings.)
b) putting this warning behind Xlint will disable it for those
who need it most: beginners.
I also chose not to refer to 'scala.util.Try' in the error message
as I think that has as much potential to confuse as it does to clarify.
|
| |\ \
| | |
| | | |
SI-6168 Retain prefix when parsing types in JVM signatures
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When reading Java classfiles, the generic signatures are
used to construct the corresponding Scala type signatures.
In the enclosed test case, the field `SomeClass.f` had
the JVM signature:
LContext<LSomeClass;>.Field<Ljava.lang.Integer;>;
The parser first (correctly) parsed the prefix as `Context[SomeClass]`.
It then looked up the type symbol for `Field` in that that type. It then
discarded the parsed prefix, and instead used the prefix from the
info of the type symbol: `Context[ParentType]`.
This commit changes the signature parser after the first `.` to
use the result of prior parsing as the prefix.
I've also included a test case with Java static inner classes,
which don't require any special treatment.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
topic/merge-2.10.x-to-v2.11.0-M2-74-g00e6c8b
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
build.xml
src/compiler/scala/reflect/reify/utils/Extractors.scala
src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
src/compiler/scala/tools/nsc/symtab/classfile/ICodeReader.scala
src/compiler/scala/tools/nsc/transform/patmat/MatchOptimization.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/partest/scala/tools/partest/nest/ReflectiveRunner.scala
src/reflect/scala/reflect/internal/Types.scala
src/reflect/scala/reflect/runtime/JavaUniverse.scala
test/files/run/inline-ex-handlers.check
test/files/run/t6223.check
test/files/run/t6223.scala
test/scaladoc/scalacheck/IndexTest.scala
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We now use the unified diff format, hence the updated check files.
It's not clear to me how partest's classpath is managed,
but the approach in this commit works for the ant task and script invocation.
The diffutils jar is injected in the parent classloader.
|
| | |\ \ \
| | | | |
| | | | | |
SI-7285 Fix match analysis with nested objects
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The fix for SI-6146 introduced `nestedMemberType` to
enumerate sealed subtypes based on the (prefixed) type
of the scrutinee and the symbols of its sealed subclasses.
That method needed to widen `ThisType(modSym)`s to
`ModuleTypeRef(modSym)` before calling `asSeenFrom`.
However, this could lead to confused in the match analysis,
which sees `ModuleTypeRef` as distinct from singleton types
on the same modules (after all, they aren't =:=). Spurious
warnings ensued.
This commit makes two changes:
- conditionally re-narrow the result of `asSeenFrom` in `nestedMemberType`.
- present `a.b.SomeModule.type` as `SomeModule` in warnings emitted
by the pattern matcher.
|
| | | | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-7290 Discard duplicates in switchable alternative patterns.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- make a def a val, we only need to compute it once
- add a clarifying comment
- only report the first duplicate
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The pattern matcher must not allow duplicates to hit the
backend when generating switches. It already eliminates then
if they appear on different cases (with an unreachability warning.)
This commit does the same for duplicated literal patterns in an
alternative pattern: discard and warn.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-6387 Clones accessor before name expansion
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When a symbol's name is expanded due to a conflict during
composition (e.g. multiple traits with same-named members, but
which are not both visible at the language level in the concrete
class) the compiler renames some symbols with expanded names which
embed the full name of the declaring class to avoid clashes.
In the rare cases when the accessor overrides the member in base
class, such expansion either results in AbstractMethodError when
the base method is abstract, or, even worse, can change the
semantics of the program.
To avoid such issues, we clone the accessor symbol, clear its
ACCESSOR flag and enter the symbol with an unchanged name.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7246 Make $outer pointer elision Java aware
|
| | | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In e0853b3, a space-saving optimization elided the outer pointer
of inner classes if the the (protected) outer pointer of the
immediate parent class was guaranteed to point to the same instance.
But, this check failed to account for Java parent classes, which
don't follow the Scala scheme. This commit disables the optimization
in that case.
The original test case in e0853b3 was anemic, I've fleshed it out to:
- test the presense or absense of $outer pointers with Java reflection
- test the optimization works in the presense of aliased and annotated
aliased types. (The former worked already, the latter required a
change to the implementation.)
- Test the negative case when the prefixes don't line up and the
subclass in fact needs its own $outer.
This patch is based on work by Euguene Vigdorchik with some
additions by Jason Zaugg.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7299 Improve error message for eta-expanding 23+ param method
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Before, we got `error: missing arguments for method f`.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Read version 51 (JDK 7) class files.
|
| | | | |/ / / /
| | |/| | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This commit makes the ClassFileReader/ICodeReader parse class files
from JDK 7 (class file version 51). It does that by skipping over
the method handle related entries in the constant pool and by doing
some dummy processing on invoke dynamic instructions. The inliner
is updated to not try to inline a method with an invoke dynamic
instruction. A place holder INVOKE_DYNAMIC instruction is added to ICode
but it is designed to create an error if there's ever any attempt to
analyze it. Because the inliner is the only phase that ever tries
to analyze ICode instructions not generated from Scala source and
because Scala source will never emit an INVOKE_DYNAMIC, the place
holder INVOKE_DYNAMIC should never cause any errors.
A test is included that generates a class file with INVOKE_DYNAMIC
and then compiles Scala code that depends on it.
|
| | |\ \ \ \ \ \
| | |_|/ / / /
| |/| | | | | |
SI-6210 Test case for already-fixed pattern matcher bug
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The fix arrived in SI-6022 / #1100 / 2.10.0-M7.
|
| | |\ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
SI-7251, compiler crash with $.
|
| | |\ \ \ \ \ \
| | |_|_|/ / /
| |/| | | | | |
SI-7253: respect binary compatibility constraints
|
| | | | |/ / /
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
From the JLS one can prove that moving a method to a superclass is a binary
compatible change, both forward and backward. That's because when compiling a
method call `c.foo()`, where c: C, the output descriptor *must* refer to `C` and
not to the class where `foo()` is actually defined.
This patch just ensures that, and adds a test comparing generated descriptors
against the Javac output.
The sample code is from Paul Philipps, the fix and the bytecode comparison code
from me.
From 2006 (9954eafffd5e60676238369ab0ed5797c92b4a7b, a fix for bug 455 in the
old bug tracker
http://www.scala-lang.org/sites/default/files/aladdin/displayItem.do%3Fid=455.html)
until 2.9, Scalac has followed this rule "often" (that is, when C is *not* an
interface).
This behavior was wrong, but the bug was hard to trigger. AFAICS, this can
create problems only when moving a method to a super interface in a library and
expecting forward binary compatibility - that is, compiling some Scala client
code against the new version of the library, and trying to run this code against
the old version of the library. This change grows an interface, so it is valid
only if clients are supposed to *not* implement the library. Apparently, this
is so rare that nobody noticed.
Since 2.10 (0bea2ab5f6b211a83bbf14ea46fe57b8163c6334), Scalac follows this rule
*only* when C is an interface (I assume by oversight, since the main change was
an accessibility check), so the bug was finally triggered.
The new code will have to emit INVOKEINTERFACE instead of INVOKEVIRTUAL a bit
more often, compared to 2.9 (but not to 2.10). I don't know whether
INVOKEINTERFACE is noticeably slower (it shouldn't be); but this is the safest
fix since this behavior is mandated by the JLS.
If somebody disagrees and believes the 2.9 is significantly faster, IMHO he
should send a separate pull request (although ProGuard is probably a better
place for the change).
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-5699 correct java parser for annotation defs.
|
| | | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Correct java source parser not to insert a constructor with the type
of its value method.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7242 Fix crash when inner object mixes in its companion
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Given:
class C {
trait T { C.this } // C$T$$$outer$ : C
object T extends T { C.this } // C$T$$$outer$ : C.this.type
}
object T ended up with a definitions for both of the accessors.
These cannot co-exist, as they have the same erased type. A crash
ensued almost immediately in explitouter.
Fortunately, the solution is straightforward: we can just omit
the mixin outer accessor altogether, the objects own outer accessor
is compatible with it.
scala> :javap C.T
Compiled from "<console>"
public interface C$T{
public abstract C C$T$$$outer();
}
scala> :javap C.T$
Compiled from "<console>"
public class C$T$ extends java.lang.Object implements C$T{
public C C$T$$$outer();
public C$T$(C);
}
I also added an assertion to give a better error message in
case we find ourselves here again.
Also includes tests from SI-3994, which I'll mark as a duplicate.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7258 Don't assume order of reflection values in t6223
|
| | | | |/ / / /
| | |/| | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
test/files/run/t6223's check file expects a specific
ordering of the reflected values. The ordering is not
guaranteed by the runtime/reflection API and can change.
Therefore, sort the values before comparing them.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7259 Fix detection of Java defined Selects
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The fix for SI-3120, 3ff7743, introduced a fallback within
`typedSelect` that accounted for the ambiguity of a Java
selection syntax. Does `A.B` refer to a member of the type `A`
or of the companion object `A`? (The companion object here is a
fiction used by scalac to group the static members of a Java
class.)
The fallback in `typedSelect` was predicated on
`context.owner.enclosingTopLevelClass.isJavaDefined`.
However, this was incorrectly including Select-s in top-level
annotations in Scala files, which are owned by the enclosing
package class, which is considered to be Java defined. This
led to nonsensical error messages ("type scala not found.")
Instead, this commit checks the compilation unit of the context,
which is more direct and correct. (As I learned recently,
`currentUnit.isJavaDefined` would *not* be correct, as a lazy type
might complete a Java signature while compiling some other compilation
unit!)
A bonus post factum test case is included for SI-3120.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7249 Reign in overzealous Function0 optimization.
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The fix for SI-1247 went too far, and could result in
premature evaluation of the expression that yields the
Function0.
This commit checks that said expression is safe to inline.
If not, a wrapper `() => ....` is still required.
The optimization is still enabled in sitations like the
original test case, run/t1247.scala.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6921 SI-7239 Tread lightly during exploratory typing
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When deciding whether an Assign is a named argument or
and assignment expression, or when looking at arguments
that the current selection is applied to in order to
evaluate candidate implicit views, we risk polluting
the tree by setting error types. This happens even
if we are in 'silent' mode; that mode does silence the
error report, but not the side effect on the tree.
This commit adds strategic `duplicate` calls to
address the problem symptomatically.
Duplicating trees and retyping in general reach into
the domain of bugs umbrella-ed under SI-5464, but in
these places we should be safe because the tree is in
the argument position, not somewhere where, for example,
a case class-es synthetic companion object might be
twice entered into the same scope.
Longer term, we'd like to make type checking side effect
free, so we wouldn't need to play whack-a-mole like this.
That idea is tracked under SI-7176.
|
| | |\ \ \ \ \ \
| | |/ / / / /
| |/| | | | | |
SI-7232 Fix Java import vs defn. binding precendence
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Java Spec:
> A single-type-import declaration d in a compilation unit c
> of package p that imports a type named n shadows, throughout
> c, the declarations of:
> - any top level type named n declared in another compilation
> unit of p
> - any type named n imported by a type-import-on-demand
> declaration in c
> - any type named n imported by a static-import-on-demand
> declaration in c
Scala Spec:
> Bindings of different kinds have a precedence defined on them:
> 1. Definitions and declarations that are local, inherited, or made
> available by a package clause in the same compilation unit where
> the definition occurs have highest precedence.
> 2. Explicit imports have next highest precedence.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
[forward-port] SI-7232 Fix Java import vs defn. binding precendence
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Java Spec:
> A single-type-import declaration d in a compilation unit c
> of package p that imports a type named n shadows, throughout
> c, the declarations of:
> - any top level type named n declared in another compilation
> unit of p
> - any type named n imported by a type-import-on-demand
> declaration in c
> - any type named n imported by a static-import-on-demand
> declaration in c
Scala Spec:
> Bindings of different kinds have a precedence defined on them:
> 1. Definitions and declarations that are local, inherited, or made
> available by a package clause in the same compilation unit where
> the definition occurs have highest precedence.
> 2. Explicit imports have next highest precedence.
This is a forward port of 6e79370, which did not merge cleanly
and was omitted in the regular merge from 2.10.x to master.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
[forward port] SI-7259 Fix detection of Java defined Selects
|
| | |/ / / / / / /
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The fix for SI-3120, 3ff7743, introduced a fallback within
`typedSelect` that accounted for the ambiguity of a Java
selection syntax. Does `A.B` refer to a member of the type `A`
or of the companion object `A`? (The companion object here is a
fiction used by scalac to group the static members of a Java
class.)
The fallback in `typedSelect` was predicated on
`context.owner.enclosingTopLevelClass.isJavaDefined`.
However, this was incorrectly including Select-s in top-level
annotations in Scala files, which are owned by the enclosing
package class, which is considered to be Java defined. This
led to nonsensical error messages ("type scala not found.")
Instead, this commit checks the compilation unit of the context,
which is more direct and correct. (As I learned recently,
`currentUnit.isJavaDefined` would *not* be correct, as a lazy type
might complete a Java signature while compiling some other compilation
unit!)
A bonus post factum test case is included for SI-3120.
Manual forward port of f046853 which was not merged as
part of the routine 2.10.x to master merge. The test case
uncovered a NullPointerExceptiion crasher in annotation
typechecking introduced in 5878099c; this has been prevented
with a null check.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
| |\ \ \ \ \ \ \ \
| |_|_|_|_|_|_|/
|/| | | | | | | |
SI-7296 Lifting the limit on case class arity
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
When venturing above the pre-ordained limit of twenty
two, `Companion extends FunctionN` and `Companion.unapply`
are sacrificed. But oh-so-many other case class features
work perfectly: equality/hashing/stringification, the apply
method, and even pattern matching (which already bypasses
unapply.)
There was some understandable fear of the piecemeal when
I tabled this idea on scala-internals [1]. But I'd like
to persist as this limit is a needless source of pain for
anyone using case classes to bind to database, XML or JSON
schemata.
[1] https://groups.google.com/forum/#!topic/scala-internals/RRu5bppi16Y
|
| | | |_|_|_|_|/
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The implementation restriction doesn't stop subsequent
typechecking in the same compilation unit from triggering
type completion which tries to synthesize the unapply
method.
This commit predicates generation of the unapply method
on having 22 or fewer parameters.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Improve testing interactive experience.
|
| | | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently the exceptions that happen in the test are swallowed, as
the JVM is forced to exit before printing the stack trace.
Also assert message doesn't contain information about the problem.
The call to "sys.exit" masks bugs in the testing framework, that
has to be addressed more elaborately, so here we remove it. Also
add the message parameter to assert to make it more informative.
After removing "sys.exit" call, doc test starts failing. I suspect
there might be a problem when expanding doc variables, but this
should be addressed separately.
|
