| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-7770 mutable.BitSet.toImmutable isn't immutable
|
| | |
| |
| |
| |
| | |
Mark method as deprecated due to it not providing the expected result,
while fixing it will break existing code.
|
| |\ \
| | |
| | | |
SI-9093 Fix value discarding / multiple param list crasher
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The type error stemming from missing argument list was being
swallowed when the expected type was `Unit` and there were
undetermined type parameters in the expression.
This commit modifies `adapt` to avoid using
`instantiateExpectingUnit` when the tree is typed with `MethodType`.
|
| |\ \ \
| | | |
| | | | |
SI-9050 Fix crasher with value classes, recursion
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
From the "Substitution is hard to do" department.
In 7babdab9a, TreeSymSubstitutor was modified to mutate the info
of symbols defined in the tree, if that symbol's info referred to
one of the `from` symbols in the substitution.
It would have been more principled to create a cloned symbol
with the updated info, and add that to the substitution. But I
wasn't able implement that correctly (let alone efficiently.)
The in-place mutation of the info of a symbol led to the crasher
in this bug: a singleton type over that symbol ends up with a stale
cached value of 'underlying'. In the enclosed test case, this leads
to a type error in the `SubstituteRecursion` of the extension
methods phase.
This commit performs a cleanup job at the end of `substituteSymbols`
by invalidating the cache of any `SingleType`-s in the tree that
refer to one of the mutated symbols.
|
| |\ \ \ \
| | | | |
| | | | | |
Document concurrent package object
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-9133 Harden against infinite loop in NoSymbol.owner
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The available evidence gathered in an IDE hang suggests that
while editing erronenous code, a call to `Erasure#javaSig` by the
IDE's structure builder triggered the `ExplicitOuter` info transformer
on a symbol with some sort of incoherent owner chain, which led to
an infinite loop in `NoSymbol#outerClass`.
This commit hardens that method to work in the same manner as a call
to `NoSymbol.owner`: log the error under -Xdev or -Ydebug and return
return `NoSymbol` to soldier on without crashing / hanging.
I haven't formulated a theory about how we might have ended up with
the corrupt owner chain.
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
SI-7623 Trailing sequence wildcard warning
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
An -Xlint:stars-align warning for the case of patterns
with at least one "fixed" component and a varargs component.
Warn if the fixed patterns don't exactly align with the fixed
value components, such that a sequence wildcard aligns exactly
with the varargs component (either a T* parameter in a case class
or a Seq[T] in an extractor result).
This addresses the case of the xml.Elem extractor, which does
not correspond to the Elem class constructor. One can be fooled
into supplying an extra field for extraction.
Vanilla extractors of type `Option[Seq[_]]` are unaffected by
this flag. It's OK to ask for `case X(a, b, c)` in the expectation
that three results are forthcoming. There is no semantic confusion
over where the varargs begin.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9072 Vector ++ concatenation of parallel collection cause inconsisten...
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
results
|
| | | | | | | | |
|
| | |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
We can now edit these in IntelliJ, as per the regular JUnit tests.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-5154 Parse leading literal brace in XML pattern
|
| | | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Don't consume literal brace as Scala pattern.
Previously, leading space would let the text parser `xText`
handle it correctly instead.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-5817: Add header to language.scala and languageFeature.scala
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
These two files were missing headers.
There is other work on-going to automate updating of the headers, but
that likely won't crossover with this.
|
| |\ \ \ \ \ \ \
| |_|_|_|_|_|/
|/| | | | | | |
SI-9087 Fix min/max of reversed Double/Float orderings
|
| | | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As diagnosed by the reporter, we needed additional overrides
due to the way these orderings are implemented.
I've added tests to show other methods and other orderings
are working correctly.
After writing that, I found a scalacheck test related to
NaN handling that also covers `Ordering`. I had to correct
the assertion in the tests of `reverse.{min,max}`.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- Rename CodeRepository to ByteCodeRepository
- Scaladoc on OptimizerReporting
- Scaladoc on ByteCodeRepository
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This infrastructure is required for the inliner: when inlining code
from a classfile, the corresponding ClassBType is needed for various
things (eg access checks, InnerClass attribute).
The test creates two ClassBTypes for the same class: once using the
(unpickled) Symbol, once using the parsed ASM ClassNode, and verifies
that the two are the same.
There's a cleanup to the InnerClass attribute:
object T { class Member; def foo = { class Local } }
class T
For Java compatibility the InnerClass entry for Member says the class
is nested in T (not in the module class T$). We now make sure to add
that entry only to T, not to T$ (unless Member is actually referenced
in the classfile T$, in that case it will be added, as required).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Introduces methods for textifying classes, methods, InsnLists and
individual AbstractInsnNodes.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
There's already the map classBTypeFromInternalNameMap in BTypes which
stores all ClassBTypes.
|
| | | | | | | |
|
| | |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Each ClassBType is identified by its internalName, the fully qualified
JVM class name. Before this change, the name was stored in the `chrs`
array of the compiler name table (hash consed), with the idea to avoid
materializing the string.
However, we materialize the string anyway, because each ClassBType is
stored in the classBTypeFromInternalNameMap, indexed by the string.
If string equality turns out to be too slow we can use interning.
For the inliner, we read classes from bytecode and create ClassBTypes
for them. The names of these classes would not yet exist in the name
table, so the backend would need to be able to create new names. Using
Strings removes this dependency.
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
SI-9089 Another REPL/FSC + specialization bug fix
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The enclosed test case stopped working in 2.11.5 on the back of
https://github.com/scala/scala/pull/4040.
The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.
In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.
This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.
I have found another spot that was directly manipulating the scope,
and removed the offending code.
[1] https://github.com/scala/scala/pull/4040#commitcomment-8531516
|
| |\ \ \ \
| | | | |
| | | | | |
Fix many typos in docs and comments
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
SI-9057 - fix `showCode` to put backticks around names including dots
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Missing backticks cause the parser to treat names as paths, which is
obviously invalid.
A unit test is included.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Fix scaladoc OutpuStream typo
|
| | | |/ / /
| |/| | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
Kornel/feature/SI-9067-enumeration-with-name-improvement
SI-9067: Enumeration withName improvement
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- Enumeration#withName in case of a failed approach to resolve the
Enumeration value fails with a meaningless NoSuchElementException.
Would be nice to know what exactly is not found
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | | |
SI-7965 Support calls to MethodHandle.{invoke,invokeExact}
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These methods are "signature polymorphic", which means that compiler
should not:
1. adapt the arguments to `Object`
2. wrap the repeated parameters in an array
3. adapt the result type to `Object`, but instead treat it as it
it already conforms to the expected type.
Dispiritingly, my initial attempt to implement this touched the type
checker, uncurry, erasure, and the backend.
However, I realized we could centralize handling of this in the typer
if at each application we substituted the signature polymorphic
symbol with a clone that carried its implied signature, which is
derived from the types of the arguments (typechecked without an
expected type) and position within and enclosing cast or block.
The test case requires Java 7+ to compile so is currently embedded
in a conditionally compiled block of code in a run test.
We ought to create a partest category for modern JVMs so we can
write such tests in a more natural style.
Here's how this looks in bytecode. Note the `bipush` / `istore`
before/after the invocation of `invokeExact`, and the descriptor
`(LO$;I)I`.
```
% cat sandbox/poly-sig.scala && qscala Test && echo ':javap Test$#main' | qscala
import java.lang.invoke._
object O {
def bar(x: Int): Int = -x
}
object Test {
def main(args: Array[String]): Unit = {
def lookup(name: String, params: Array[Class[_]], ret: Class[_]) = {
val lookup = java.lang.invoke.MethodHandles.lookup
val mt = MethodType.methodType(ret, params)
lookup.findVirtual(O.getClass, name, mt)
}
def lookupBar = lookup("bar", Array(classOf[Int]), classOf[Int])
val barResult: Int = lookupBar.invokeExact(O, 42)
()
}
}
scala> :javap Test$#main
public void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC
Code:
stack=3, locals=3, args_size=2
0: aload_0
1: invokespecial #18 // Method lookupBar$1:()Ljava/lang/invoke/MethodHandle;
4: getstatic #23 // Field O$.MODULE$:LO$;
7: bipush 42
9: invokevirtual #29 // Method java/lang/invoke/MethodHandle.invokeExact:(LO$;I)I
12: istore_2
13: return
LocalVariableTable:
Start Length Slot Name Signature
0 14 0 this LTest$;
0 14 1 args [Ljava/lang/String;
13 0 2 barResult I
LineNumberTable:
line 16: 0
}
```
I've run this test across our active JVMs:
```
% for v in 1.6 1.7 1.8; do java_use $v; pt --terse test/files/run/t7965.scala || break; done
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:02)
Test Run PASSED
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:07)
Test Run PASSED
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
Selected 1 tests drawn from specified tests
.
1/1 passed (elapsed time: 00:00:05)
Test Run PASSED
```
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-9044 Fix order of interfaces in classfiles
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It was reversed since ced3ca8ae1. The reason is that the backend used
`mixinClasses` to obtain the parents of a class, which returns them in
linearization order.
`mixinClasses` als returns all ancestors (not only direct parents),
which means more work for `minimizeInterfaces`. This was introduced
in cd62f52 for unclear reasons. So we switch back to using `parents`.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9011 Speculative fix for CCE in Scala IDE
|
| | | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Based on the reported stack trace and what I know of Scala IDE,
I've changed `InteractiveNamer#enterExistingSymbol` to be `DocDef`
aware.
I haven't provided a test as this was not minimized from Scala IDE.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8999 Reduce memory usage in exhaustivity check
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The OOM could occur when all models are forcibly expanded in the DPLL solver.
The simplest solution would be to limit the number of returned models but then
we are back in non-determinism land (since the subset we get back depends on
which models were found first).
A better alternative is to create only the models that have corresponding
counter examples.
If this does not ring a bell, here's a longer explanation:
TThe models we get from the DPLL solver need to be mapped back to counter
examples. However there's no precalculated mapping model -> counter example.
Even worse, not every valid model corresponds to a valid counter example.
The reason is that restricting the valid models further would for example
require a quadratic number of additional clauses. So to keep the optimistic case
fast (i.e., all cases are covered in a pattern match), the infeasible counter
examples are filtered later.
The DPLL procedure keeps the literals that do not contribute to the solution
unassigned, e.g., for `(a \/ b)` only {a = true} or {b = true} is required and
the other variable can have any value. This function does a smart expansion of
the model and avoids models that have conflicting mappings.
For example for in case of the given set of symbols (taken from `t7020.scala`):
"V2=2#16"
"V2=6#19"
"V2=5#18"
"V2=4#17"
"V2=7#20"
One possibility would be to group the symbols by domain but
this would only work for equality tests and would not be compatible
with type tests.
Another observation leads to a much simpler algorithm:
Only one of these symbols can be set to true,
since `V2` can at most be equal to one of {2,6,5,4,7}.
TODO: How does this fare with mixed TypeConst/ValueConst assignments?
When the assignments are e.g., V2=Int | V2=2 | V2=4, only the assignments
to value constants are mutually exclusive.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7459 Handle pattern binders used as prefixes in TypeTrees.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Match translation was incorrect for:
case t => new t.C
case D(t) => new d.C
We would end up with Types in TypeTrees referring to the wrong
symbols, e.g:
// t7459a.scala
((x0$1: this.LM) => {
case <synthetic> val x1: this.LM = x0$1;
case4(){
matchEnd3(new tttt.Node[Any]())
};
matchEnd3(x: Any){
x
}
Or:
// t7459b.scala
((x0$1: CC) => {
case <synthetic> val x1: CC = x0$1;
case4(){
if (x1.ne(null))
matchEnd3(new tttt.Node[Any]())
else
case5()
};
This commit:
- Changes `bindSubPats` to traverse types, as well as terms,
in search of references to bound symbols
- Changes `Substitution` to reuse `Tree#substituteSymbols` rather
than the home-brew substitution from `Tree`s to `Tree`s, if the
`to` trees are all `Ident`s
- extends `substIdentsForTrees` to substitute selections like
`x1.caseField` into types.
I had to dance around the awkward handling of "swatches" (exception
handlers that can be implemented with JVM native type switches) by
duplicating trees to avoid seeing the results of `substituteSymbols`
in `caseDefs` after we abandon that approach if we detect the
patterns are too complex late in the game.
I also had to add an escape hatch for the "type selection from
volatile type" check in the type checker. Without this, the
translation of `pos/t7459c.scala`:
case <synthetic> val x1: _$1 = (null: Test.Mirror[_]).universe;
case5(){
if (x1.isInstanceOf[Test.JavaUniverse])
{
<synthetic> val x2: _$1 with Test.JavaUniverse = (x1.asInstanceOf[_$1 with Test.JavaUniverse]: _$1 with Test.JavaUniverse);
matchEnd4({
val ju1: Test.JavaUniverse = x2;
val f: () => x2.Type = (() => (null: x2.TypeTag[Nothing]).tpe);
.. triggers that error at `x2.TypeTag`.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Suppress match analysis under -Xno-patmat-analysis
|
