| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
package object
- The corresponding `apply` methods in the `Future` and `Promise` objects
should be used instead.
- Adjusted tests to use non-deprecated versions
- Fixed doc comments not to use deprecated methods
- Added comment about planned removal in 2.13.0
|
| |\
| |
| | |
Paulper stack reduction
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Restores a form of the previous peekAhead bookkeeping.
Instead of tracking the current token and offset outside
of xxxAhead, peekingAhead uses `in.prev` and will push
back if the operation results in an empty tree.
|
| | |
| |
| |
| | |
Check files
|
| | |
| |
| |
| |
| |
| |
| | |
Centralizes the scattered logic surrounding erroneous
pattern syntax. Consolidates the redundant lookahead
implementations. Eliminates var manipulation in favor
of recursion.
|
| |\ \
| |/
|/| |
Avoid needless TypeRef allocation during erasure.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- ThisType(some.package) need not be erased, we can let
that prefix through unchanged and avoid churning through
allocations.
- Sharpen the condition in `rebindInnerClass`. The answer
to the deleted comment in the code, is "anonymous and
local classes", which are specifically excluded in the
new formulation.
- Finally, detect if erasure of the TypeRef is an identity and reuse
the original.
Waste not, want not.
To expand on the first point, here is what used to happen during
erasure:
scala> val scalaPack = typeOf[Predef.type].prefix
scalaPack: $r.intp.global.Type = scala.type
scala> typeDeconstruct.show(scalaPack)
res19: String = ThisType(package scala)
scala> typeDeconstruct.show(erasure.scalaErasure(scalaPack))
res20: String = TypeRef(TypeSymbol(final class scala extends ))
Showing one step of the erasure type map:
scala> typeDeconstruct.show(scalaPack.asInstanceOf[SubType].underlying.typeOfThis)
res21: String = SingleType(pre = ThisType(package <root>), package scala)
|
| |\ \
| |/
|/| |
Topic/tidy collections
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Collections library tidying, part one: scripting.
Everything in scala.collection.scripting is deprecated now, along with the
<< method that is implemented in a few other classes. Scripting does not
seem used at all, and anyone who did can easily write a wrapper that does
the same thing.
Deprecated *Proxy collections.
The only place proxies were used in the library was in swing.ListView, and
that was easy to change to a lazy val.
Proxy itself is used in ScalaNumberProxy and such, so it was left
undeprecated.
Deprecated Synchronized* traits from collections.
Synchronizability does not compose well, and it requires careful examination
of every method (which has not actually been done).
Places where the Scala codebase needs to be fixed (eventually) include:
scala.reflect.internal.util.Statistics$QuantMap
scala.tools.nsc.interactive.Global (several places)
Deprecated LinkedList (including Double- and -Like variants).
Interface is idiosyncratic and dangerously low-level. Although some
low-level functionality of this sort would be useful, this doesn't seem
to be the ideal implementation.
Also deprecated the extractFirst method in Queue as it exposes LinkedList.
Cannot shift internal representations away from LinkedList at this time
because of that method.
Deprecated non-finality of several toX collection methods.
Improved documentation of most toX collection methods to describe what the
expectation is for their behavior. Additionally deprecated overriding of
- toIterator in IterableLike (should always forward to iterator)
- toTraversable in TraversableLike (should always return self)
- toIndexedSeq in immutable.IndexedSeq (should always return self)
- toMap in immutable.Map (should always return self)
- toSet in immutable.Set (should always return self)
Did not do anything with IterableLike.toIterable or Seq/SeqLike.toSeq since
for some odd reason immutable.Range overrides those.
Deprecated Forwarders from collections.
Forwarding, without an automatic mechanism to keep up to date with changes
in the forwarded class, is inherently unreliable. Absent a mechanism to
keep current, they're deprecated. ListBuffer is the only class in the
collections library that uses forwarders, and that functionality can be
rolled into ListBuffer itself.
Deprecating immutable set/map adaptors.
They're a bad idea (barring compiler support) for the same reason that all
the other adaptors are a bad idea: they get out of date and probably have a
variety of performance bugs.
Deprecated inheritance from leaf classes in immutable collections.
Inheriting from leaf-classes in immutable collections is rarely a good idea
since whenever you use any interesting collections method you'll revert to
the original class. Also, the methods are often designed to work with only
particular behavior, and an override would be difficult (at best) to make
work. Fortunately, people seem to have realized this and there are few to
no cases of people extending PagedSeq and TreeSet and the like.
Note that in many cases the classes will become sealed not final.
Deprecated overriding of methods and inheritance from various mutable
collections.
Some mutable collections seem unsuited for overriding since to override
anything interesting you would need vast knowledge of internal data
structures and/or access to private methods. These include
- ArrayBuilder.ofX classes.
- ArrayOps
- Some methods of BitSet (moved others from private to protected final)
- Some methods of HashTable and FlatHashTable
- Some methods of HashMap and HashSet (esp += and -= which just forward)
- Some methods of other maps and sets (LinkedHashX, ListMap, TreeSet)
- PriorityQueue
- UnrolledBuffer
This is a somewhat aggressive deprecation, the theory being better to try it
out now and back off if it's too much than not attempt the change and be
stuck with collections that can neither be safely inherited nor have
implementation details changed.
Note that I have made no changes--in this commit--which would cause
deprecation warnings in any of the Scala projects available on Maven (at
least as gathered by Adriaan). There are deprecation warnings induced
within the library (esp. for classes/traits that should become static) and
the compiler. I have not attempted to fix all the deprecations in the
compiler as some of them touch the IDE API (but these mostly involved
Synchronized which is inherently unsafe, so this should be fixed
eventually in coordination with the IDE code base(s)).
Updated test checks to include new deprecations.
Used a higher level implementation for messages in JavapClass.
|
| |\ \
| | |
| | | |
Small implicit optimizations, and SI-7678 RunDefinitions
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.
This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.
In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.
The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.
The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.
|
| |\ \
| |/
|/| |
SI-7776 post-erasure signature clashes are now macro-aware
|
| | |
| |
| |
| |
| |
| |
| | |
"double definition: macro this and method that have same type after erasure"
This error doesn't make sense when macros are involved, because macros
expand at compile-time, where we're not affected by erasure. Moreover,
macros produce no bytecode, which means that we're safe from VerifyErrors.
|
| |\ \
| | |
| | | |
SI-7634 resurrect the REPL's :sh command
|
| | | |
| | |
| | |
| | |
| | |
| | | |
ProcessResult had a companion object in 2.10 that somehow disappeared in
2.11. It only called "new ProcessResult(...)", so the REPL might just as
well do that.
|
| |\ \ \
| | | |
| | | | |
Delay delambdafication and put the lambda's body into the containing class
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The differences when running with method based delambdafication aren't
important enough yet to create specialized versions that use method
based delambdafication.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit includes several tests where there's a variation in
signatures between inline delambdafication and method based
delambdafication.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
During development of late delmabdafying there was a problem where
specialization would undo some of the work done in uncurry if the body
of the lambda had a constant type. That would result in a compiler crash
as when the delambdafy phase got a tree shape it didn't understand.
This commit has a fix and a test.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
During development of delayed delambdafy there was a problem where
GenASM would eliminate a loadmodule for all methods defined within that
module even if those methods were static. The result would be broken
byte code that failed verification. This commit fixes that and adds a
test.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit puts a real body on the Delambdafy phase.
From a lambda, Delambdafy will create
1) a static forwarder at the top level of the class that contained
the lambda
2) a new top level class that
a) has fields and a constructor taking the captured environment
(including possbily the "this" reference)
b) an apply method that calls the static forwarder
c) if needed a bridge method for the apply method
3) an instantiation of the newly created class which replaces the
lambda
Trees.scala is modified to add two more convenient factories
for templates and classdefs.
A few basic tests are included to verify that it works as expected.
Further commits will have additional tests.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
the body of a lambda into a local def. Tests are included to show the
different tree shapes.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit adds a do-nothing phase called "Delambdafy" that will
eventually be responsible for doing the final translation of lambdas
into classes.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The future-spec tests were spawning threads in object constructors which
meant they were on the ragged edge of entering deadlock from the static
initialization lock acquired during the static initialization blocks we
use to construct object reference fields. My work on restructuring
lambdas pushed it over the edge. This commit refactors the tests to use
class constructors rather than object constructors.
|
| |\ \ \ \
| |_|_|/
|/| | | |
- parallel collections should use default ExecutionContext
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Parallel collections now use `scala.concurrent.ExecutionContext`
by default.
The `ExecutionContextTaskSupport` is optimized to use the
`ForkJoinPool` underlying the `ExecutionContext` if possible.
Otherwise, a fallback `TaskSupport` that creates a reduction tree and
execute an operation through `Future`s is used.
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Implicit search created a nested Context into which the results of
its typechecking, namely, errors and undetermined type parameters
(roughly: those inferred as Nothing) are stashed.
The code the drives the process was checking for errors, but
discarded those undetermined type parameters.
This commit copies them from the child context to the parent,
which lets `Typer#adapt` to get to:
else if (hasUndetsInMonoMode) { // (9)
assert(!context.inTypeConstructorAllowed, context) //@M
instantiatePossiblyExpectingUnit(tree, mode, pt)
}
Our lost TypeVar has found its way home! The reward for which
is being instantiated, based on another type inference session
adapting the expression's type to the expected type.
|
| |\ \ \
| | | |
| | | | |
SI-7605 Deprecate procedure syntax
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit covers three cases:
- constructor definitions (def this {...})
- concrete method definitions (def foo {...})
- abstract method declarations (def foo)
The deprecation is currently hidden behind -Xfuture pending IDE support
for migrating users from procedures to methods.
|
| |\ \ \ \
| |_|/ /
|/| | | |
SI-6385 Avoid bridges to identical signatures over value classes
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As Paul noted in the comments to SI-6260 (from which I mined some
test cases) "there is no possible basis for conflict here":
scala> class C[A](val a: Any) extends AnyVal
defined class C
scala> class B { def x[A](ca: C[A]) = () }
defined class B
scala> class D extends B { override def x[A](ca: C[A]) = () }
<console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D
which overrides method x: [A](ca: C[A])Unit in class B
clashes with definition of the member itself;
both have erased type (ca: Object)Unit
class D extends B { override def x[A](ca: C[A]) = () }
^
What was happening?
Bridge computation compares `B#x` and `D#x` exitingErasure, which
results in comparing:
ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)])
These types were considered distinct (on the grounds of the unique
type hash consing), even though they have the same erasure and
involve the same value class.
That triggered creation of an bridge. After post-erasure eliminates
the `ErasedValuedType`s, we find that this marvel of enginineering is
bridges `(Object)Unit` right back onto itself. The previous
resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed
that we detected the zero-length bridge and reported it nicely, which
happened after related work in SI-6260. But we can simply avoid
creating in it in the first place.
That's what this commit does. It does so by reducing the amount
of information carried in `ErasedValueType` to the bare minimum needed
during the erasure -> posterasure transition.
We need to know:
1. which value class wraps the value, so we can box and unbox
as needed
2. the erasure of the underlying value, which will replace this
type in post-erasure.
This construction means that the bridge above computation now
compares:
ErasedValueType(C, Any) =:= ErasedValueType(C, Any])
I have included a test to show that:
- we don't incur any linkage or other runtime errors in the
reported case (run/t6385.scala)
- a similar case compiles when the signatures align
(pos/t6260a.scala), but does *not* compile when the just
erasures align (neg/t6260c.scala)
- polymorphic value classes continue to erase to the instantiated
type of the unbox: (run/t6260b.scala)
- other cases in SI-6260 remains unsolved and indeed unsolvable
without an overhaul of value classes: (neg/t6260b.scala)
In my travels I spotted a bug in corner case of null, asInstanceOf
and value classes, which I have described in a pending test.
|
| | | | |
| | | |
| | | |
| | | | |
(for f in $(find test -name '*.check' -o -name '*.flags'); do bare=$(echo $f | sed -E 's/\.\w+$//'); ([[ -f "$bare" ]] || [[ -d "$bare" ]] || [[ -f "$bare.scala" ]] || [[ -f "$bare.test" ]] || echo $f) done;) | xargs rm
|
| |/ / /
| | |
| | |
| | | |
for f in $(find test -name '*.check' -o -name '*.flags'); do [[ $(wc -c $f | sed -E 's/ *([0-9]+).*/\1/') == "0" ]] && rm $f; done
|
| |\ \ \
| | | |
| | | | |
Favour module accessors symbols in rebind
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The Refchecks tree transformer transforms a nested modules that
overrides a method into a pair of symbols: the module itself, and
an module accessor that matches the overridden symbol.
[[syntax trees at end of typer]] // test1.scala
package <empty> {
abstract trait C2 extends scala.AnyRef {
def O1: Any
};
class C1 extends AnyRef with C2 {
object O1 extends scala.AnyRef
}
}
[[syntax trees at end of refchecks]] // test1.scala
package <empty> {
abstract trait C2 extends scala.AnyRef {
def O1: Any
};
class C1 extends AnyRef with C2 {
object O1 extends scala.AnyRef
@volatile <synthetic> private[this] var O1$module: C1.this.O1.type = _;
<stable> def O1: C1.this.O1.type = {
C1.this.O1$module = new C1.this.O1.type();
C1.this.O1$module
}
}
}
When constructing a TypeRef or SingleType with a prefix and and a symbol,
the factory methods internally use `rebind` to see if the provided symbol
should be replaced with an overriding symbol that is available in that prefix.
Trying this out in the REPL is a bit misleading, because even if you change
phase to `refchecks`, you won't get the desired results because the transform
is not done in an InfoTransformer.
scala> val O1 = typeOf[C1].decl(TermName("O1"))
O1: $r.intp.global.Symbol = object O1
scala> typeRef(typeOf[C2], O1, Nil)
res13: $r.intp.global.Type = C2#O1
scala> res13.asInstanceOf[TypeRef].sym.owner
res14: $r.intp.global.Symbol = class C1
But debugging the test case, we get into `rebind` during an AsSeenFrom
which is where we crashed when `suchThat` encountered the overloaded
module and module accessor symbols:
typeOf[OuterObject.Inner.type].memberType(symbolOf[InnerTrait.Collection])
...
singleTypeAsSeen(OuterTrait.this.Inner.type)
val SingleType(pre, sym) = tp
// pre = OuterTrait.this.type
// sym = OuterTrait.Inner
val pre1 = this(pre) // OuterObject.type
singleType(pre1, sym)
rebind(pre1, sym) // was crashing, now OuterObject.Inner
}
This commit excludes the module symbol from symbol lookup in the prefix in rebind.
|
| | | | |
| | | |
| | | |
| | | | |
Patern translation now happens earlier.
|
| |\ \ \ \
| |_|/ /
|/| | | |
Tests for protected access
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I've marked a few minor cases in the test with !!! where I believe
the behaviour goes beyond the spec.
|
| | | | |
| | | |
| | | |
| | | | |
c39f26382dddaa7 fixed the bug but didn't commit a test case.
|
| |\ \ \ \
| | | | |
| | | | | |
Filter JVM debug output for custom options in partest
|
| | | | | |
| | | | |
| | | | |
| | | | | |
The Picked up _JAVA_OPTIONS line occurs on Sun's JDK as a debug output when you use that variable to set up custom VM options
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-6840 fixes weird typing of quasiquote arguments
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously quasiquote arguments were type checked against Any
which caused weird inference that made splicing of complex expressions
unusable:
val l1 = List(q"foo")
val l2 = List(q"bar")
q"f(..${l1 ++ l2})" // argument type checked as Any instead of List[Tree]
This is fixed by forcing compiler to type check against type
variable which itself isn't used in any other way.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
better macro impl shape errors
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
With the advent of quasiquotes, we allowed both arguments and return types
of macro impls to be c.Tree's (as opposed to traditional c.Expr[T]'s).
This warrants an update of macro def <-> macro impl signature mismatch
errors that include a printout of suggested macro impl signatures. Now
along with a signature that contains exprs, we suggest another signature
that has all exprs replaced by trees
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Deterministic warnings for pattern matcher, take 2
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The previous swing at determinism, ebb01e05cbe4, made decent
contact but apparently didn't hit it out of the park. The test
wavered every hundred or so runs, as witnessed occasionally in
nightly builds or pull request validation.
I setup a test to run neg/7020.scala a few hundred times, and
could trigger the failure reliably.
I then swept through the pattern matcher in search of HashMap and
HashSet creation, and changed them all to the Linked variety.
The results of that are published in retronym#ticket/7020-3 [1].
This commit represents the careful whittling down of that patch
to the minimal change required to exhibit determinism.
[1] https://github.com/retronym/scala/compare/ticket/7020-3
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7519: Additional test case covering sbt/sbt#914
|
| | | |/ / / / /
| |/| | | | | |
|
| |\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | | |
fixes handling of fancy nested classes in runtime reflection
|
