| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Fixes the index/length comparison in `Vector#take` and `Vector#drop` so that they handle all possible integer values.
Given the collection's invariants `startIndex >= endIndex` and `0 >= startIndex, endIndex`, it is sufficient to change the arithmetic in the comparison as done in this commit to avoid overflows. As cases when `n <= 0` are handled beforehand, `endIndex - n` cannot overflow, contrary to `startIndex + n`. If without the danger of overflows the condition yields true, on the other hand, `startIndex + n` cannot overflow as it is smaller than `endIndex` (as the previous formulation of the condition shows).
|
|\
| |
| | |
Multi output problem with delambdafied compilation
|
| | |
|
|/
|
|
| |
When dealing with mutable collections, it is not safe to assume iterators will remain consistent when the collection is modified mid-traversal. The bug reported in SI-9497 is very similar to SI-7269, "ConcurrentModificationException when filtering converted Java HashMap". Then, only the `retain` method was fixed. This commit fixes `clear`, which had the same problem.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A trio of problems were hampering autocompletion of annotations.
First, given that that annotation is written before the annotated
member, it is very common to end parse incomplete code that has a
floating annotation without an anotatee.
The parser was discarding the annotations (ie, the modifiers) and
emitting an `EmptyTree`.
Second, the presetation compiler was only looking for annotations
in the Modifiers of a member def, but after typechecking annotations
are moved into the symbol.
Third, if an annotation failed to typecheck, it was being discarded
in place of `ErroneousAnnotation`.
This commit:
- modifies the parser to uses a dummy class- or type-def tree,
instead of EmptyTree, which can carry the annotations.
- updates the locator to look in the symbol annotations of the
modifiers contains no annotations.
- uses a separate instance of `ErroneousAnnotation` for each
erroneous annotation, and stores the original tree in its
`original` tree.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the code:
```
s"${fooo<CURSOR"
```
The parser treats `fooo` as a interpolator ID for the quote that
we actually intend to end the interpolated string.
Inserting a space (in addition to `__CURSOR__` that we already
patch in to avoid parsing a partial identifier as a keyword),
solves this problem.
|
|\
| |
| | |
Topic/completely 2.11
|
| |
| |
| |
| |
| |
| |
| | |
Recover part of the identifier that preceded the cursor from the
source, rather than from the name in the `Select` node, which might
contains an encoded name that differs in length from the one in
source.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm pretty sure the `isSynthetic` call added in 854de25ee6 should
instead be `isArtifact`, so that's what I've implemented here.
`isSynthetic` used to also filter out error symbols, which are
created with the flags `SYNTHETIC | IS_ERROR`. I've added an addition
test for `isError`, which was needed to keep the output of
`presentation/scope-completion-import` unchanged.
The checkfile for `presentation/callcc-interpreter` is modified to
add the additional completion proposals: synthetic companion objects.
|
| |
| |
| |
| |
| |
| | |
When `foo.<TAB>`, assume you don't want to see the inherited members
from Any_ and universally applicable extension methods like
`ensuring`. Hitting <TAB> a second time includes them in the results.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For the SHIFT-impaired: you can just write everything in lowercase,
(whisper-case?) and we'll try to DWYM.
We treat capital letters that you *do* enter as significant, they
can't match a lower case letter in an identifier.
Modelled after IntellIJ's completion.
I still don't fall into this mode if you enter an exact prefix of
a candidate, but we might consider changing that.
```
scala> classOf[String].typ<TAB>
getAnnotationsByType getComponentType getDeclaredAnnotationsByType getTypeName getTypeParameters
scala> classOf[String].typN<TAB>
scala> classOf[String].getTypeName
res3: String = java.lang.String
scala> def foo(s: str<TAB>
scala> def foo(s: String
String StringBuffer StringBuilder StringCanBuildFrom StringContext StringFormat StringIndexOutOfBoundsException
scala> def foo(s: string<TAB>
scala> def foo(s: String
String StringBuffer StringBuilder StringCanBuildFrom StringContext StringFormat StringIndexOutOfBoundsException
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is just too useful to leave on the cutting room floor.
```
scala> classOf[String].enclo<TAB>
scala> classOf[String].getEnclosing
getEnclosingClass getEnclosingConstructor getEnclosingMethod
scala> classOf[String].simpl<TAB>
scala> classOf[String].getSimpleName
type X = global.TTWD<TAB>
scala> type X = global.TypeTreeWithDeferredRefCheck
```
I revised the API of `matchingResults` as it was clunky to reuse
the filtering on accessibility and term/type-ness while providing
a custom name matcher.
|
| | |
|
| |
| |
| |
| |
| | |
Trying harder to keep the synthetic interpretter wrapper classes
behind the curtain
|
| |
| |
| |
| |
| | |
This makes life easier for clients of these APIs, we use this
to avoid passing this around in the wrapper result `TypeMembers`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The old implementation is still avaiable under a flag, but we'll
remove it in due course.
Design goal:
- Push as much code in src/interactive as possible to enable reuse
outside of the REPL
- Don't entangle the REPL completion with JLine. The enclosed test
case drives the REPL and autocompletion programatically.
- Don't hard code UI choices, like how to render symbols or
how to filter candidates.
When completion is requested, we wrap the entered code into the
same "interpreter wrapper" synthetic code as is done for regular
execution. We then start a throwaway instance of the presentation
compiler, which takes this as its one and only source file, and
has a classpath formed from the REPL's classpath and the REPL's
output directory (by default, this is in memory).
We can then typecheck the tree, and find the position in the synthetic
source corresponding to the cursor location. This is enough to use
the new completion APIs in the presentation compiler to prepare
a list of candidates.
We go to extra lengths to allow completion of partially typed
identifiers that appear to be keywords, e.g `global.def` should offer
`definitions`.
Two secret handshakes are included; move the the end of the line,
type `// print<TAB>` and you'll see the post-typer tree.
`// typeAt 4 6<TAB>` shows the type of the range position within
the buffer.
The enclosed unit test exercises most of the new functionality.
|
|\ \
| | |
| | | |
SI-9388 Fix Range behavior around Int.MaxValue
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
terminalElement (the element _after_ the last one!) was used to terminate foreach loops and sums of non-standard instances of Numeric. Unfortunately, this could result in the end wrapping around and hitting the beginning again, making the first element bad.
This patch fixes the behavior by altering the loop to end after the last element is encountered. The particular flavor was chosen out of a few possibilities because it gave the best microbenchmarks on both large and small ranges.
Test written. While testing, a bug was also uncovered in NumericRange, and was also fixed. In brief, the logic around sum is rather complex since division is not unique when you have overflow. Floating point has its own complexities, too.
Also updated incorrect test t4658 that insisted on incorrect answers (?!) and added logic to make sure it at least stays self-consistent, and fixed the range.scala test which used the same wrong (overflow-prone) formula that the Range collection did.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
See https://github.com/scala/scala-parser-combinators/issues/70
Basically the same thing as SI-6615, including the fact everything
works okay if the PagedSeq is printed before calling slice.
It might seem strange that this allows taking slices that start beyond
the end, but
- this was possible anyway if one forced the entire sequence, and
- it is reasonable to be able to take a slice at the very end (not
beyond it) and get an empty sequence, which is exactly what
StreamReader in scala-parser-combinators does and gets an NPE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|\
| |
| | |
Closure elimination for new backend
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ASM has a built-in `SourceValue` analysis which computes for each
value a set of instructions that may possibly have constructed it.
The ProdConsAnalyzer class provides additional queries over the
result of the SourceValue analysis:
- consumers of values
- tracking producers / consumers through copying operations (load,
store, etc)
A fix to (and therefore a new version of) ASM was required. See here:
https://github.com/scala/scala-asm/commit/94106a5472
|
|/ |
|
|\
| |
| | |
Fix illegal inlining of instructions accessing protected members
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There were two issues in the new inliner that would cause a
VerifyError and an IllegalAccessError.
First, an access to a public member of package protected class C can
only be inlined if the destination class can access C. This is tested
by t7582b.
Second, an access to a protected member requires the receiver object
to be a subtype of the class where the instruction is located. So
when inlining such an access, we need to know the type of the receiver
object - which we don't have. Therefore we don't inline in this case
for now. This can be fixed once we have a type propagation analyis.
https://github.com/scala-opt/scala/issues/13.
This case is tested by t2106.
Force kmpSliceSearch test to delambdafy:inline
See discussion on https://github.com/scala/scala/pull/4505. The issue
will go away when moving to indy-lambda.
|
|\ \
| | |
| | | |
fix BigDecimal losing MathContext
|
| | | |
|
| | | |
|
| |/ |
|
| |
| |
| |
| |
| | |
Fix exclusive floating point ranges to contain also the last element
when the end-start difference is not an integer multiple of step.
|
|\ \
| | |
| | | |
Clean implementation of sorts for scala.util.Sorting.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Removed code based on Sun JDK sorts and implemented new (basic) sorts from
scratch. Deferred to Java Arrays.sort whenever practical. Behavior of
`scala.util.Sorting` should be unchanged, but changed documentation to
specify when the Java methods are being used (as they're typically very fast).
A JUnit test is provided.
Performance is important for sorts. Everything is better with this patch,
though it could be better yet, as described below.
Below are sort times (in microseconds, SEM < 5%) for various 1024-element
arrays of small case classes that compare on an int field (quickSort), or
int arrays that use custom ordering (stableSort). Note: "degenerate"
means there are only 16 values possible, so there are lots of ties.
Times are all with fresh data (no re-using cache from run to run).
Results:
```
random sorted reverse degenerate big:64k tiny:16
Old Sorting.quickSort 234 181 178 103 25,700 1.4
New Sorting.quickSort 170 27 115 74 18,600 0.8
Old Sorting.stableSort 321 234 236 282 32,600 2.1
New Sorting.stableSort 239 16 194 194 25,100 1.2
java.util.Arrays.sort 124 4 8 105 13,500 0.8
java.util.Arrays.sort|Box 126 15 13 112 13,200 0.9
```
The new versions are uniformly faster, but uniformly slower than Java sorting. scala.util.Sorting has use cases that don't map easily in to Java unless everything is pre-boxed, but the overhead of pre-boxing is minimal compared to the sort.
A snapshot of some of my benchmarking code is below.
(Yes, lots of repeating myself--it's dangerous not to when trying to get
somewhat accurate benchmarks.)
```
import java.util.Arrays
import java.util.Comparator
import math.Ordering
import util.Sorting
import reflect.ClassTag
val th = ichi.bench.Thyme.warmed()
case class N(i: Int, j: Int) {}
val a = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt, i)) )
var ai = 0
val b = Array.fill(1024)( Array.tabulate(1024)(i => N(i, i)) )
var bi = 0
val c = Array.fill(1024)( Array.tabulate(1024)(i => N(1024-i, i)) )
var ci = 0
val d = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt(16), i)) )
var di = 0
val e = Array.fill(16)( Array.tabulate(65536)(i => N(util.Random.nextInt, i)) )
var ei = 0
val f = Array.fill(65535)( Array.tabulate(16)(i => N(util.Random.nextInt, i)) )
var fi = 0
val o = new Ordering[N]{ def compare(a: N, b: N) = if (a.i < b.i) -1 else if (a.i > b.i) 1 else 0 }
for (s <- Seq("one", "two", "three")) {
println(s)
th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Sorting.quickSort(x)(o); x(x.length/3) }
th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Sorting.quickSort(x)(o); x(x.length/3) }
}
def ix(ns: Array[N]) = {
val is = new Array[Int](ns.length)
var i = 0
while (i < ns.length) {
is(i) = ns(i).i
i += 1
}
is
}
val p = new Ordering[Int]{ def compare(a: Int, b: Int) = if (a > b) 1 else if (a < b) -1 else 0 }
for (s <- Seq("one", "two", "three")) {
println(s)
val tag: ClassTag[Int] = implicitly[ClassTag[Int]]
th.pbench{ val x = ix(a(ai)); ai = (ai+1)%a.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(b(bi)); bi = (bi+1)%b.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(c(ci)); ci = (ci+1)%c.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(d(di)); di = (di+1)%d.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(e(ei)); ei = (ei+1)%e.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
th.pbench{ val x = ix(f(fi)); fi = (fi+1)%f.length; Sorting.stableSort(x)(tag, p); x(x.length/3) }
}
for (s <- Seq("one", "two", "three")) {
println(s)
th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Arrays.sort(x, o); x(x.length/3) }
th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Arrays.sort(x, o); x(x.length/3) }
}
def bx(is: Array[Int]): Array[java.lang.Integer] = {
val Is = new Array[java.lang.Integer](is.length)
var i = 0
while (i < is.length) {
Is(i) = java.lang.Integer.valueOf(is(i))
i += 1
}
Is
}
def xb(Is: Array[java.lang.Integer]): Array[Int] = {
val is = new Array[Int](Is.length)
var i = 0
while (i < is.length) {
is(i) = Is(i).intValue
i += 1
}
is
}
val q = new Comparator[java.lang.Integer]{
def compare(a: java.lang.Integer, b: java.lang.Integer) = o.compare(a.intValue, b.intValue)
}
for (s <- Seq("one", "two", "three")) {
println(s)
val tag: ClassTag[Int] = implicitly[ClassTag[Int]]
th.pbench{ val x = bx(ix(a(ai))); ai = (ai+1)%a.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(b(bi))); bi = (bi+1)%b.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(c(ci))); ci = (ci+1)%c.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(d(di))); di = (di+1)%d.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(e(ei))); ei = (ei+1)%e.length; Arrays.sort(x, q); xb(x)(x.length/3) }
th.pbench{ val x = bx(ix(f(fi))); fi = (fi+1)%f.length; Arrays.sort(x, q); xb(x)(x.length/3) }
}
```
|
|\ \ \
| |/ /
|/| | |
Nullness Analysis for GenBCode
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Address feedback in #4516 / 57b8da4cd8. Save allocations of
NullnessValue - there's only 4 possible instances. Also save tuple
allocations in InstructionStackEffect.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When inlining an instance call, the inliner has to ensure that a NPE
is still thrown if the receiver object is null. By using the nullness
analysis, we can avoid emitting this code in case the receiver object
is known to be not-null.
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Tracks nullness of values using an ASM analyzer.
Tracking nullness requires alias tracking for local variables and
stack values. For example, after an instance call, local variables
that point to the same object as the receiver are treated not-null.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Since the leading and trailing iterators returned by span
share the underlying iterator, the leading iterator must
flag when it is exhausted (when the span predicate fails)
since the trailing iterator will advance the underlying
iterator.
It would also be possible to leave the failing element in
the leading lookahead buffer, where it would forever fail
the predicate, but that entails evaluating the predicate
twice, on both enqueue and dequeue.
|
|\
| |
| | |
SI-9254 UnrolledBuffer appends in wrong position
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed two bugs in insertion (insertAll of Unrolled):
1. Incorrect recursion leading to an inability to insert past the first chunk
2. Incorect repositioning of `lastptr` leading to strange `append` behavior after early insertion
Added tests checking that both of these things now work.
Also added a comment that "waterlineDelim" is misnamed. But we can't fix it now--it's part of the public API. (Shouldn't be, but it is.)
|
|\ \
| | |
| | | |
SI-9197 Duration.Inf not a singleton when deserialized
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Made `Duration.Undefined`, `.Inf`, and `.MinusInf` all give back the singleton instance instead of creating a new copy by overriding readResolve.
This override can be (and is) private, which at least on Sun's JDK8 doesn't mess with the auto-generated SerialVersionUIDs.
Thus, the patch should make things strictly better: if you're on 2.11.7+ on JVMs which pick the same SerialVersionUIDs, you can recover singletons. Everywhere else you were already in trouble anyway.
|
|\ \
| | |
| | | |
SI-9275 Fix row-first display in REPL
|