| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
[backport] SI-7470 implements fundep materialization
|
| |
| |
| |
| |
| |
| |
| |
| | |
To quote gkossakowski:
Thinking about it more, could we hide this behind 'Y' flag instead?
We have lesser obligation to keep around Y flags and this is something
we should remove from 2.11/2.12.
|
| | |
|
| |
| |
| |
| |
| | |
Backports 21a8c6c from the 2.11.x branch under -Xfundep-materialization
as per Miles Sabin's request. Thanks Miles!
|
|\ \
| | |
| | | |
[backport] SI-8787 Backport Regex doc
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Backport the doc with two material changes:
1. need to use Groups to extract from Match,
so say that in lieu of the 2.11 advice that
the Regex instance can be used without
recomputing the match;
2. and relatedly, in 2.10 there is no secondary
constructor, so the doc for group names is
moved back up to the class doc.
Original doc update on PR #3923 was:
0e26910372d349c6ff7bbaa17fc8fe0bf568c5fe
f98c53cb03f800b3d790f3866ab90f827fd131f5
|
|\ \
| | |
| | | |
[backport] transformers no longer ignore UnApply.fun
|
| |/
| |
| |
| | |
Backports 7122560063 and 4133eb8454 from the 2.11.x branch
|
|\ \
| | |
| | | |
[backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Backport of scala/scala-parser-combinators@91584dc.
---
Starting with 1.7.0_06 [1], String.substring no longer reuses the internal
char array of the String but make a copy instead. Since we call
subSequence twice for *every* input character, this results in horrible
parse performance and GC.
With the benchmark from the (duplicate) ticket SI-8542, I get:
BEFORE:
parseAll(new StringReader(String))
For 100 items: 49 ms
For 500 items: 97 ms
For 1000 items: 155 ms
For 5000 items: 113 ms
For 10000 items: 188 ms
For 50000 items: 1437 ms
===
parseAll(String)
For 100 items: 4 ms
For 500 items: 67 ms
For 1000 items: 372 ms
For 5000 items: 5693 ms
For 10000 items: 23126 ms
For 50000 items: 657665 ms
AFTER:
parseAll(new StringReader(String))
For 100 items: 43 ms
For 500 items: 118 ms
For 1000 items: 217 ms
For 5000 items: 192 ms
For 10000 items: 196 ms
For 50000 items: 1424 ms
===
parseAll(String)
For 100 items: 2 ms
For 500 items: 8 ms
For 1000 items: 16 ms
For 5000 items: 79 ms
For 10000 items: 161 ms
For 50000 items: 636 ms
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6924259
|
|\ \
| | |
| | | |
Prevent SI-8314 by adding a test
|
|/ /
| |
| |
| | |
The original issue was fixed already. This test is just for make sure.
|
|\ \
| |/
|/| |
SI-8589 Performance improvement for ArrayCharSequence.toString
|
|/ |
|
|\
| |
| | |
SI-8596 Fix rangepos crasher with defaults, poly methods
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regressed in SI-7915 / 3009a525b5
We should be deriving the position of the synthetic `Select`
from `basefun1`, rather than `basefun`. In the new, enclosed
test, the difference amounts to:
new Container().typeParamAndDefaultArg[Any]()
`------------ basefun1 --------------'
`----------------- basefun ---------------'
For monomorphic methods, these are one and the same, which is
why `presentation/t7915` was working. I've extended that test
to a polymorphic method to check that hyperlink resolution works.
|
|\
| |
| | |
SI-8479 Fix constructor default args under scaladoc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `DocDef` node hid the `DefDef` constructor from the scrutinee
of the namer when determining if the class had constructor defaults
or not.
The current pattern for fixing these bugs is to delegate the check
to `TreeInfo`, and account for the wrapper `DocDef` node. I've
followed that pattern, but expressed my feelings about this approach
in a TODO comment.
Before this patch, the enclosed test failed with:
error: not enough arguments for constructor SparkContext: (master: String, appName: String)SparkContext
|
|\ \
| | |
| | | |
SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
And update the java `ClassFileParser` to create distinguished
`StubClassSymbol`s, rather that a regular `ClassSymbol`s, when
encountering a deficient classpath. This brings it into line
with `Unpickler`, which has done as much since a55788e275f.
This stops the enclosed test case from crashing when determining
if the absent symbol, `A_1`, is a subclass of `@deprecated`.
This is ostensibly fixes a regression, although it only worked in
`2.10.[0-3]` by a fluke: the class file parser's promiscious
exception handling caught and recovered from the NPE introduced
in SI-7439!
% javac -d /tmp test/files/run/t8442/{A,B}_1.java && qbin/scalac -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala && (rm /tmp/A_1.class; true) && scalac-hash v2.10.0 -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala
warning: Class A_1 not found - continuing with a stub.
warning: Caught: java.lang.NullPointerException while parsing annotations in /tmp/B_1.class
two warnings found
|
|\ \
| | |
| | | |
[nomaster] backports 609047ba37
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MemberDefs alone can't be typechecked as is, because namer only names
contents of PackageDefs, Templates and Blocks. And, if not named, a tree
can't be typed.
This commit solves this problem by wrapping typecheckees in a trivial block
and then unwrapping the result when it returns back from the typechecker.
(cherry picked from commit 609047ba372ceaf06916d3361954bc949a6906ee)
|
|\ \ \
| | | |
| | | | |
SI-8196 Runtime reflection robustness for STATIC impl details
|
| | | |
| | | |
| | | |
| | | | |
Which was fixed in the previous commit.
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Scala's runtime reflection works in few modes. The primary mode reads
reads out the pickled signatures from ScalaSig annotations, if
avaialable. However, these aren't available for Java-defined classes
(obviously) nor for local Scala-defined classes (less obviously.),
and the Scala `Symbol`s and `Types` must be reconstructed from
the Java generic reflection metadata.
This bug occurs in the last case, and is centered in
`FromJavaClassCompleter`.
In that completer, member fields and methods are given an owner
based on the STATIC modifier. That makes sense for Java defined
classes. I'm not 100% if it makes sense for Scala defined classes;
maybe we should just skip them entirely?
This patch still includes them, but makes the ownership-assignment
more robust in the face of STATIC members emitted by the Scala
compiler backend, such as the cache fields for structural calls.
(It's reflection all the way down!). We might not have a companion
module at all, so before we ended up owning those by `NoSymbol`,
and before too long hit the dreaded NSDHNAO crash.
That crash doesn't exist any more on 2.11 (it is demoted to a
-Xdev warning), but this patch still makes sense on that branch.
This commit makes `followStatic` and `enter` more robust when
finding a suitable owner for static members. I've also factored
out the duplicated logic between the two.
|
|\ \ \
| | | |
| | | | |
[backport] no longer warns on calls to vampire macros
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.
However, since such macros are on the intersection of a number of language
features, as usual, there are bugs.
This commit fixes an unwanted interaction of macros defined in structural
types with the scala.language.reflectiveCalls guard. Since macro calls
aren't going to be carried to runtime, there's no need to warn about them.
|
|\ \ \
| |/ /
|/| | |
Bump version to 2.10.5 for nightly builds.
|
|/ / |
|
|\ \
| |/
|/| |
[backport] SI-7902 Fix spurious kind error due to an unitialized symbol
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tracked down this error:
<none> is invariant, but type Y2 is declared covariant
<none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any
to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol
was not initialized.
This happends in the enclosed test for:
// checkKindBoundsHK()
hkArgs = List(type M3)
hkParams = List(type M2)
This commit forces the symbol of the higher-kinded type argument
before checking kind conformance.
A little backstory:
The `List(NoSymbol)` arises from:
class PolyTypeCompleter... {
// @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`),
// otherwise, the non-skolemized (external) type parameter symbols
override val typeParams = tparams map (_.symbol)
The variation that triggers this problem gets into the kind
conformance checks quite early on, during naming of:
private[this] val x = ofType[InSeq]
The inferred type of which is forced during:
def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match {
case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) =>
// If we don't save the annotations, they seem to wander off.
val annotations = stat.symbol.initialize.annotations
(cherry picked from commit 03a06e02483eaf442158339c2edd6bcfd99847a3)
|
|\
| |
| | |
SI-8205 [nomaster] backport test pos.lineContent
|
| |
| |
| |
| | |
Verifies previous behavior.
|
|\ \
| | |
| | | |
[nomaster] corrects an error in reify’s documentation
|
|/ / |
|
|\ \
| | |
| | | |
[backport] Backports library changes related to SI-6566 from a419799
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The idea of backporting this occured while developing the -source flag
for SI-8126 : withouth this the library breaks at refchecks for a
Scala compiler that checks type aliases variance.
This shoudl be BC and promote good hygiene.
|
|\ \ \
| | | |
| | | | |
[nomaster] Fix non-deterministic <:< for deeply nested types
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Backported from master. This is a squashed commmit comprising:
SI-8146 Pending test, diagnosis for bug in decidability of <:<
(cherry picked from commit 8beeef339ad65f3308ece6fb0440cdb31b1ad404)
SI-8146 Test cases for typechecking decidability
Taken from "On Decidability of Nominal Subtyping with Variance"
(Pierce, Kennedy), which was implemented in 152563b.
Part of the implementation (SubTypePair) will be changed in the
following commit to fix the non-deterministic errors typechecking
heavily nested types involving aliases or annotations.
(cherry picked from commit 2e28cf7f76c3d5fd0c2df4274f1af9acb42de699)
SI-8146 Fix non-deterministic <:< for deeply nested types
In the interests of keeping subtyping decidable [1], 152563b
added some bookkeeping to `isSubType` to detect cycles.
However, this was based on a hash set containing instances of
`SubTypePair`, and that class had inconsistencies between its
`hashCode` (in terms of `Type#hashCode`) and `equals`
(in terms of `=:=`).
This inconsistency can be seen in:
scala> trait C { def apply: (Int @unchecked) }
defined trait C
scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType
intUnchecked: $r.intp.global.Type = Int @unchecked
scala> val p1 = new SubTypePair(intUnchecked, intUnchecked)
p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked
scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations)
p2: $r.intp.global.SubTypePair = Int <:<? Int
scala> p1 == p2
res0: Boolean = true
scala> p1.hashCode == p2.hashCode
res1: Boolean = false
This commit switches to using `Type#==`, by way of the standard
case class equality.
The risk here is that you could find a subtyping computation that
progresses in such a manner that we don't detect the cycle. It would
need to produce an infinite stream of representations for types that
were `=:=` but not `==`. If that happened, we'd fail to terminate,
rather than judging the relationship as `false`.
[1] http://research.microsoft.com/pubs/64041/fool2007.pdf
(cherry picked from commit a09e143b7fd1c6b433386d45e9c5ae3548819b59)
Conflicts:
src/reflect/scala/reflect/internal/tpe/TypeComparers.scala
src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
scala.reflect.internal._ now gets a free pass from binary
compatibility checking.
Previously, we had to excrutiatingly exclude violations individually.
|
|\ \ \ \
| | | | |
| | | | | |
Fix bug with super-accessors / dependent types
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Super-accessors are generated as `DefDef`'s with `EmptyTree` as a
placeholder for the RHS. This is filled in later in `Mixin` in
`completeSuperAccessor`.
A change in `Uncurry` (SI-6443 / 493197f), however, converted this
to a `{ EmptyTree }`, which evaded the pattern match in mixin.
This commit adds a special case to the dependent method treatment
in Uncurry to avoid generating redundant blocks.
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
[nomaster] Backport variance validator performance fix
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
% time qbin/scalac test/files/pos/t8146-performance.scala
real 0m2.015s
user 0m2.892s
sys 0m0.215s
% time scalac-hash v2.10.3 test/files/pos/t8146-performance.scala
real 1m13.652s
user 1m14.245s
sys 0m0.508s
Cherry-picks one hunk from 882f8e64.
|
|\ \ \ \
| |/ / /
|/| | | |
Repair symbol owners after abandoned named-/default-args
|
| | | |
| | | |
| | | |
| | | |
| | | | |
As everone knows, undo/reset/retype/rollback are bandaids; we
should try to treat the disease more directly.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Names/Defaults eagerly transforms an application with temporaries
to maintain evaluation order, and dutifully changes owners of
symbols along the way.
However, if this approach doesn't work out, we throw away this
and try a auto-tupling. However, we an still witness symbols
owned by the temporaries.
This commit records which symbols are owned by the context.owner
before `transformNamedApplication`, and rolls back the changes
before `tryTupleApply`.
Perhaps a better approach would be to separate the names/defaults
applicability checks from the evaluation-order-preserving transform,
and only call the latter after we have decided to go that way.
|
|\ \ \ \
| | | | |
| | | | | |
[nomaster] Binary compat. workaround for erasure bug
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We can't backport SI-7120 to 2.10.x as it changes erased signatures,
which can lead to interop problems between 2.10.3 and 2.10.4.
But, we can detect one of the nasty symptoms -- a bridge method
with the same signature as its target -- and treat that.
This commit detects duplicate bridges in the ASM (only) backend
and removes them.
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
More clear implicitNotFound error for ExecutionContext
|