| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Test that closes SI-5839. Bug itself most probably fixed by #602
|
| | | |
|
| |\ \
| | |
| | | |
removes pre-M4 compatibility stubs for the IDE
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
patmat bugfixes and minor clean ups
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
TODO: t5899 should also be refactored, but I couldn't figure out how
I tried the obvious Cake Light pattern with abstract types etc, but that didn't trigger it
there must be something with indirection through paths as well
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
Closes SI-5148.
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Unfortunately we have to wrap transform to catch all
the MissingRequirementErrors exceptions (wrapped in TypeErrors).
This is because we force the info of the symbol in a couple of
places and we would have to catch all/some of them
(and remove the duplicates as well which really becomes messy).
Review by @axel22.
|
| | | | |
|
| |/ /
| |
| |
| |
| | |
Seems that my cleanup of SI-4842 also fixed that one.
Review by @paulp or @retronym.
|
| |\ \
| | |
| | | |
Minor followup on SI-4842: remove awkward condition. Review by @retronym
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
SI-4989 Reject super.x if an intermediate class declares x abstract.
|
| | | |
| | |
| | |
| | |
| | | |
This is in line with Java's treatment. Without this, an AbstractMethodError
is thrown at runtime.
|
| |\ \ \
| | | |
| | | | |
SI-2807 Resurrect and refine the promiscuous catch warning.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous incarnation didn't survive 4fb3473.
This version can be cleared by using a typed pattern: `catch { case _: Throwable => }`.
This is motivated by the recent appearance of such a catch in `util.Try`, and by battle
scars left by one too many processes bravely but stupidly catching and logging OutOfMemoryErrors.
-Y status has been skipped: this warning is enabled by default and can only be silenced
with use of a typed pattern.
|
| |\ \ \
| | | |
| | | | |
SI-4842 Forbid access to in-construction this in self-constructor args
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
The check was already in place for direct calls to the super constructor.
Without this additional check, ExplicitOuter crashes, as it doesn't create
an $outer pointer for the constructor-arg scoped inner object, but expects
one to exist when transforming the Outer.this reference.
|
| |\ \ \
| |_|/
|/| | |
SI-5617 Better error message for "x overrides nothing".
|
| | |/
| |
| |
| | |
"It looks like you're trying to override a method", notes Clippy.
|
| |\ \
| | |
| | | |
Fix SI-4541.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Catch type errors when duplicating trees.
In this case, to access a protected member from a specialized
class is an error, so we would have to make the member public
anyway.
Better it is then to report an error and have the user make the
field public explicitly.
Review by @dragos.
|
| |\ \
| | |
| | | |
enables reification of anonymous classes
|
| | |/ |
|
| |\ \
| |/
|/| |
SI-4270 Disqualify in scope implicits that are shadowed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If an expression wouldn't type check explicitly, it shouldn't be
allowed implicitly.
Employs typedIdent, which already does this sort of thing rather well,
instead of continuing to reimplement it in Implicits.
Remove check for non-implicit synonym, which is subsumed by typing an Ident.
Workaround Scaladoc oddity, by using an attributed select when the context
is deficient.
|
| |\ \
| | |
| | | |
SI-5696 Detect excess constructor argument lists.
|
| | | |
| | |
| | |
| | | |
An apply method fooled the usual mechanism.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
If the target method is defined in Java, treat the super reference
as an error, otherwise allow it in the knowledge that Scala loosens
the access restrictions on its generated classes.
Moves the test for that bug out of pending-ville. It's sufficient
to place Test in the empty package to exercise the right code paths.
|
| |\ \
| | |
| | | |
SI-4831 Fix ambiguous import detection for renamed imports.
|
| | |/ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consts are hashconsed modulo static-approximation-for-dynamic-value-equality
thus, two value-equality tests in patterns should reuse the same ValueConst
if and only if the tested values are guaranteed to be equal in all possible executions
the implementation uses unique types to track unique consts
for an Ident with a stable symbol, we simply use the corresponding singleton type
for a Select, we have to indirect some more: we store all the unique trees we've encountered and a unique type for each of them
this unique type is then used to find the uniqut const that approximates the run-time value
this may seem roundabout, but we need to standardize on types for representing "value" tests,
as a type test against a singleton type must give rise to the same ValueConst
as a value test using a tree that refers to the same symbol as the singleton type test
|
| |
|
|
|
| |
This protects everyone from the confusion caused by stuff like this:
https://issues.scala-lang.org/browse/SI-5884
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before 2.10 we had a notion of ClassManifest that could be used to retain
erasures of abstract types (type parameters, abstract type members) for
being used at runtime.
With the advent of ClassManifest (and its subtype Manifest)
it became possible to write:
def mkGenericArray[T: Manifest] = Array[T]()
When compiling array instantiation, scalac would use a ClassManifest
implicit parameter from scope (in this case, provided by a context bound)
to remember Ts that have been passed to invoke mkGenericArray and
use that information to instantiate arrays at runtime (via Java reflection).
When redesigning manifests into what is now known as type tags, we decided
to explore a notion of ArrayTags that would stand for abstract and pure array
creators. Sure, ClassManifests were perfectly fine for this job, but they did
too much - technically speaking, one doesn't necessarily need a java.lang.Class
to create an array. Depending on a platform, e.g. within JavaScript runtime,
one would want to use a different mechanism.
As tempting as this idea was, it has also proven to be problematic.
First, it created an extra abstraction inside the compiler. Along with class tags
and type tags, we had a third flavor of tags - array tags. This has threaded the
additional complexity though implicits and typers.
Second, consequently, when redesigning tags multiple times over the course of
Scala 2.10.0 development, we had to carry this extra abstraction with us, which
exacerbated the overall feeling towards array tags.
Finally, array tags didn't fit into the naming scheme we had for tags.
Both class tags and type tags sound logical, because, they are descriptors for
the things they are supposed to tag, according to their names.
However array tags are the odd ones, because they don't actually tag any arrays.
As funny as it might sound, the naming problem was the last straw
that made us do away with the array tags. Hence this commit.
|
| | |
|
| |
|
|
|
| |
Rather than stub implementations. This saves over 50K of bytecode.
I also added the necessary imports to silence the feature warnings.
|
| |\
| |
| | |
SI-5683 Fail gracefully when transposing a ragged type arg matrix.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The code used to do this, until `transpose` starting throwing IAE
rather than AIOOBE.
Symptomatic treatment only: The reported crasher now infers ill-kinded
type args and reports an error.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
I should not have merged this pull request yet.
I didn't notice we didn't have a full successful run of the test suite.
It looks like it breaks test/files/continuations-neg/lazy.scala and
given the pending amount of changes, I prefer to have a stable master.
This reverts commit 037d3dcbc5896864aec0f9121eeda23fcc4cd610.
|
| |\ \
| | |
| | |
| | | |
Don't compute least upper bounds for if-like exprs in statement position
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
inside blocks.
This may save huge amount of time (Fixes SI-5862) for complicated lubs. I had to remove the a check in adapt for
the part that transforms <expr> into { <expr>; () } when the expected type is Unit. The reason is in the
code.
As a side effect, we get more warnings for pure expressions in statement positions (see the change in the test file).
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analyze matches for unreachable cases.
A case is unreachable if it implies its preceding cases.
Call `C` the formula that is satisfiable if the considered case matches.
Call `P` the formula that is satisfiable if the cases preceding it match.
The case is reachable if there is a model for `-P /\ C`.
Thus, the case is unreachable if there is no model for `-(-P /\ C)`,
or, equivalently, `P \/ -C`, or `C => P`.
Unreachability needs a more precise model for type and value tests than exhaustivity.
Before, `{case _: Int => case 1 =>}` would be modeled as `X = Int \/ X = 1.type`,
and thus, the second case would be reachable if we can satisfy `X != Int /\ X = 1.type`.
Of course, the case isn't reachable, yet the formula is satisfiable, so we must augment
our model to take into account that `X = 1.type => X = Int`.
This is done by `removeVarEq`, which models the following axioms about equality.
It does so to retain the meaning of equality after replacing `V = C` (variable = constant)
by a literal (fresh symbol). For each variable:
1. a sealed type test must result in exactly one of its partitions being chosen
(the core of exhaustivity)
2. when a type test is true, tests of super types must also be true,
and unrelated type tests must be false
For example, `V : X ::= A | B | C`, and `A => B` (since `A extends B`).
Coverage (1) is formulated as: `A \/ B \/ C`, and the implications of (2) are simply
`V=A => V=B /\ V=X`, `V=B => V=X`, `V=C => V=X`.
Exclusion for unrelated types typically results from matches such as `{case SomeConst =>
case OtherConst => }`. Here, `V=SomeConst.type => !V=OtherConst.type`. This is a
conservative approximation. If these constants happen to be the same value dynamically
(but the types don't tell us this), the last case is actually unreachable. Of course we
must err on the safe side.
We simplify the equality axioms as follows (in principle this could be done by the
solver, but it's easy to do before solving). If we've already excluded a pair of
assignments of constants to a certain variable at some point, say `(-A \/ -B)`, then
don't exclude the symmetric one `(-B \/ -A)`. (Nor the positive implications `-B \/ A`,
or `-A \/ B`, which would entail the equality axioms falsifying the whole formula.)
TODO: We should also model dependencies between variables: if `V1` corresponds to
`x: List[_]` and `V2` is `x.hd`, `V2` cannot be assigned at all when `V1 = null` or
`V1 = Nil`. Right now this is implemented hackily by pruning counter-examples in exhaustivity.
Unreachability would also benefit from a more faithful representation.
I had to refactor some of the framework, but most of it is shared with exhaustivity. We
must allow approximating tree makers twice, sharing variables, but using different
approximations for values not statically known. When considering reachability of a case,
we must assume, for example, that its unknown guard succeeds (otherwise it would wrongly
be considered unreachable), whereas unknown guards in the preceding cases must be
considered to fail (otherwise we could never get to those case, and again, it would
falsely be considered unreachable).
Since this analysis is relatively expensive, you may opt-out using `-Xno-patmat-analysis`
(or annotating the selector with @unchecked). We hope to improve the performance in the
near future. -Ystatistics has also been extended to provide some numbers on time spent in
the equality-rewrite, solving and analyzing.
|
| |\
| |
| | |
SI-5845 Advances the example from a crasher to an inference failure.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The inference failure itself seems like an instance of of SI-3346.
But dependent method types (which triggered the crash), can be employed
to avoid inferring the type constructor CC.
class Num[T] {
def mkOps = new Ops
class Ops { def +++(rhs: T) = () }
}
class A {
implicit def infixOps[T](lhs: T)(implicit num: Num[T]): num.Ops = num.mkOps
implicit val n1: Num[Int] = new Num[Int] { }
5 +++ 5
}
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Are these -msil checkfiles used in some secret fashion? The level of
activity suggest otherwise. Since scala-nightly-msil has been disabled
for over a year, it's an easy rm unless someone speaks up.
% tools/rm-orphan-checkfiles
Scanning for orphan check files...
rm 'test/disabled/run/code.check'
rm 'test/files/jvm/t1652.check'
rm 'test/files/neg/macro-argtype-mismatch.check'
rm 'test/files/neg/macro-noncompilertree.check'
rm 'test/files/neg/macro-nontree.check'
rm 'test/files/run/Course-2002-01-msil.check'
rm 'test/files/run/Course-2002-02-msil.check'
rm 'test/files/run/Course-2002-03-msil.check'
rm 'test/files/run/Course-2002-04-msil.check'
rm 'test/files/run/Course-2002-08-msil.check'
rm 'test/files/run/Course-2002-09-msil.check'
rm 'test/files/run/Course-2002-10-msil.check'
rm 'test/files/run/absoverride-msil.check'
rm 'test/files/run/bitsets-msil.check'
rm 'test/files/run/boolord-msil.check'
rm 'test/files/run/bugs-msil.check'
rm 'test/files/run/impconvtimes-msil.check'
rm 'test/files/run/infix-msil.check'
rm 'test/files/run/iq-msil.check'
rm 'test/files/run/macro-invalidret-doesnt-conform-to-impl-rettype.check'
rm 'test/files/run/macro-rettype-mismatch.check'
rm 'test/files/run/misc-msil.check'
rm 'test/files/run/promotion-msil.check'
rm 'test/files/run/richs-msil.check'
rm 'test/files/run/runtime-msil.check'
rm 'test/files/run/tuples-msil.check'
rm 'test/pending/jvm/t1464.check'
rm 'test/pending/run/subarray.check'
rm 'test/pending/run/t0446.check'
rm 'test/pending/run/t5629.check'
Scanning for orphan flags files...
rm 'test/files/neg/macro-argtype-mismatch.flags'
rm 'test/files/neg/macro-noncompilertree.flags'
rm 'test/files/neg/macro-nontree.flags'
rm 'test/files/pos/anyval-children.flags'
rm 'test/files/pos/t3097.flags'
rm 'test/files/run/macro-invalidret-doesnt-conform-to-impl-rettype.flags'
rm 'test/files/run/macro-rettype-mismatch.flags'
|
| |\
| |
| | |
Test case closes SI-4818
|
| | |
| |
| |
| | |
Fixed between 2.10.0 M2 and M3, with both the old and new pattern matcher.
|
| |\ \
| | |
| | | |
SI-5318 Make implicit divergence checking PolyType aware.
|
