| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-5652 Mangle names of potentially public lambda lifted methods.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This can happen if they are accessed from an inner class. If a
subclass is happens to lift a public method to the same name,
a VerifyError ensues.
The enclosed tests:
- demonstrate the absense of the VerifyError
- show the names generated for the lifted methods (which are
unchanged if not called from an inner class, or if lifted
into a trait implementation class.)
- ensure that the callers are rewritten to call the correct
method when multiple with the same name are lifted.
It's not ideal that this phase needs a priori knowledge of the
later phases to perform this mangling. A better fix would defer
this until the point when the methods are publicised, and leave
the unmangled private method in place and install an public,
mangled forwarder.
|
| |\ \
| | |
| | | |
Fix SI-5853.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This solves two issues.
First, up to now the newly generated symbols for normalized
members were not being added to the declaration list of the
owner during `specialize`. Now they are.
Second, during `extmethods`, the extension methods generated
get an additional curried parameter list for `$this`.
Trouble was, after that, during `uncurry` and before `specialize`,
these curried parameter lists were merged into one list.
Specialization afterwards treats extension methods just
like normal methods and generates new symbols without the
curried parameter list.
The `extensionMethod` now takes this into account by checking
if the first parameter of a potential extension method has
the name `$this`.
Review by @dragos.
Review by @odersky.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Reduce time spent in lubs by making depth more adaptive. It now takes into account separately the depth of the lub types and the maximal depth of theior base type sequences. It cuts depth more aggressively if it is the base types instead of the types themselves that grow deep.
The old truncation behavior is retained under option -Xfull-lubs
Another change is that we now track depth more precisely, which should also help or at least allow better statistics.
Also added statistics that measure #lubs and time spent in them.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
the pattern `(_: T)` is made checkable using (ct: ClassTag[T]).unapply
by rewriting it to `ct(_: T)` (if there's a ClassTag[T] available)
similarly for extractors: if the formal type of the unapply method
is an uncheckable type, wrap in the corresponding classtag extractor (if available)
don't trigger rewrite on non-toplevel unchecked types
(i.e., only look at type constructor part of T when looking for unchecked types)
TODO: find outer match to figure out if we're supposed to be unchecked
would like to give users a chance to opt-out from the wrapping,
but finding the match to which this pattern belongs turned out to be tricky...
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This is necessary because toolboxes will no longer be available from the library.
Christopher Vogt will take care of the second reincarnation of DynamicRef.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As a result, hardwired macros don't need implementation stubs.
This is very important, because in a few commits scala.reflect.makro.Context
will move out from scala-library.jar.
Also adding fast track entries doesn't require jumping through hoops
with PDTs. It's as simple as defining PartialFunction[Tree, Any].
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Fixes SI-5857. More efficient min and max in Range and NumericRange
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Override `min` and `max` in `Range` and `NumericRange`
to check if a default `Ordering` for the numeric type
in question is used.
If so, bypass traversal and compute the minimum or
maximum element.
|
| |\ \ \ \
| | | | |
| | | | | |
Add the first iteration of the `util.hashing` package.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Move `MurmurHash3` to `util.hashing`.
Make the `class` private and retain a public companion
`object`, and put the `MurmurHash3.Hashing` implementations
for various types in the companion.
Add a method which composes `ByteswapHashing` with some other hashing.
Rename `hashOf` to `hash`.
Fix chi-square test in a test-case.
Review by @jsuereth.
Moved a failing test that seems to use some other library version to pending.
|
| |/ / /
| | |
| | |
| | |
| | | |
Rather than stub implementations. This saves over 50K of bytecode.
I also added the necessary imports to silence the feature warnings.
|
| |\ \ \
| | | |
| | | | |
Fix SI-5880.
|
| | |/ /
| | |
| | |
| | | |
Add a ChiSquare test for the new hash code.
|
| |\ \ \
| | | |
| | | | |
Fix SI-5867.
|
| | |/ /
| | |
| | |
| | | |
Override clone for unrolled buffer.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix a bug where a key in an immutable hash map
have the corresponding value different in the iteration
than when doing lookup. This use to happen after calling
`merge`.
Fix the order in which a key-value pair appears in
the collision resolution function - the first argument
always comes from the `this` hash map.
Deprecate `merge` in favour of `merged`, as this is
a pure method.
As an added benefit, the syntax for invoking `merge`
is now nicer.
|
| |\ \
| | |
| | | |
Implementing Hashing typeclass
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Move `Hashing` to `scala.util.hashing`.
Adde `Hashing.Default` to `Hashing` companion object.
Change `TrieMap` to autoswitch from `Hashing.Default` to `TrieMap.MangledHashing`.
|
| | | |
| | |
| | |
| | | |
Make Equiv serializable.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Modify TrieMap to use hashing and equality.
Modify serialization in TrieMap appropriately.
|
| |\ \ \
| | | |
| | | | |
SI-5313 Revert to two traversals in substThisAndSym.
|
| | |/ /
| | |
| | |
| | | |
Partially reverts 334872e.
|
| |\ \ \
| | | |
| | | | |
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).
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Unreachability analysis for pattern matches
Thanks for reviewing, @retronym!
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ / |
|
| |\ \
| | |
| | | |
fix t5843
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
SI-4579 Yoke the power of lisp.scala as a stress for the optimizer.
|
| | | | |
| | | |
| | | |
| | | | |
The reported bug was fixed between 2.10.0-M1 and 2.10.0-M2.
|
| |\ \ \ \
| | | | |
| | | | | |
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
}
|
| |\ \ \ \
| |_|/ /
|/| | | |
fixes for exhaustivity
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| | |
Fix a NSDNHAO in extension methods.
|
