| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This is the key ingredient so TypeTree(sym) can resist
widening the type.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation had come to depend on finalResultType
accidentally doing things beyond its charter - in particular,
widening types. After hunting down and fixing the call sites
depending on the bugs, I was able to rewrite the method to do
only what it's supposed to do.
I threw in a different way of writing it entirely to suggest how
some correctness might be obtained in the future. It's a lot
harder for a method written like this to break.
|
|\
| |
| | |
SI-7622 Clean Up Phase Assembly
|
| |
| |
| |
| | |
Restores the verbiage "run right after".
|
| |
| |
| |
| |
| |
| |
| |
| | |
Let optimiser components and continuations plugin opt-out
when required flags are not set.
Wasted time on a whitespace error in check file, so let
--debug dump the processed check file and its diff.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Plugins can interrogate options and declare themselves not
enabled. The plugin itself can return false from its init
if the options do not compute. A plugin phase component
can declare itself not enabled, same as an internal phase.
No one exploits this facility at this commit.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Refactor the calculation of the "phase chain" a bit.
In particular, initial and terminal phases are not special
except that they must be head and last.
When done, filter for enabled phases. At this commit,
nobody claims to be disabled.
Additional sanity support of phases settings.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Fixing hash on nodes makes fault detection deterministic,
which aids testing.
Error messages are shortened and .dot files are dumped
automatically on faults to guard against future flakiness.
|
|\ \
| | |
| | | |
merge 2.10.x to master
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/compiler/scala/tools/nsc/ast/parser/Parsers.scala
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/compiler/scala/tools/nsc/transform/ExtensionMethods.scala
|
| | |\ \ \
| | | | | |
| | | | | | |
SI-7818 Cast our way out of extended existential angst
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`substituteSymbols` is not sophisticated enough to
operate on `TypeSkolem`-s which are based on one of the
"from" symbols.
The pertinant usage of `substituteSymbols` for this bug in
in `Extender`. Recapping on that transform:
// orig
class C[T](...) extends AnyVal { def foo[U] = <rhs> }
// transform
class C[T] extends AnyVal { ... }
object C { def foo$extension[T', U'] = <rhs'> }
Where `<rhs'>` has been subtituted with, among other things,
`[T, U] ~> [T', U']`.
In this case our expected type contains a new type parameter
(of the extension method), whereas the type of the RHS contains
an existential skolem still pinned to the corresponding class type
parameter.
tree.tpe = Observable1#7037[_$1#12344]
<_$1#12344>.info = <: T#7040
pt = Observable1#7037[T#15644]
The limitation of substution is lamented in the comments
of `adaptMismatchedSkolems`, which faces the harder version of
the issue where the skolems are in the expected type.
But, we're in the "easy" case with the skolems in the tree's type;
we can cast our way out of the problem.
See also f335e447 / ed915c54.
|
| | |\ \ \ \
| | | | | | |
| | | | | | | |
SI-7767 avoid rejecting Scaladoc comments in early initializers
|
| | | |\ \ \ \
| | | | |/ / /
| | | |/| | |
| | | | | | | |
Test case for SI-7767
|
| | | |/ / / |
|
| | |\ \ \ \
| | | | | | |
| | | | | | | |
SI-7269 Rework MapLike#retains to account for desugaring change
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
`MapLike#retains` contains a for-comprehension that relied on the strict
`filter` by its generator. You can't, in general, iterate a mutable map
and remove items in the same pass.
Here's the history of the desugaring of:
def retain[A, B](thiz: mutable.Map[A, B])(p: (A, B) => Boolean): thiz.type = {
thiz.foreach {
case (k, v) =>
if (p(k, v)) thiz -= k
}
Before regression (c82ecabad6~1):
thiz.filter(((check$ifrefutable$1) => check$ifrefutable$1: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => true
case _ => false
})).withFilter(((x$1) => x$1: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
})).foreach(((x$2) => x$2: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
}));
After regression (c82ecabad6, which incorrectly assumed in the parser that
no filter is required for isInstanceOf[Tuple2])
thiz.withFilter(((x$1) => x$1: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
})).foreach(((x$2) => x$2: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
}));
After the reversion of c82ecabad6, v2.10.2
This is also after 365bb2b4e, which uses `withFilter` rather than `filter`.
thiz.withFilter(((check$q$1) => check$ifrefutable$1: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => true
case _ => false
})).withFilter(((x$1) => x$1: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
})).foreach(((x$2) => x$2: @scala.unchecked match {
case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
}));
This commit does the same as `SetLike#retains`, and converts the map to
an immutable list before the rest of the operation.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Some tests for specialization use a modified version of
the standard library that count boxing, array lookups etc.
These sources are updated manually with the script:
% test/instrumented/mkinstrumented.sh build
Looks that that wasn't done for a while, though.
This commit brings it up to date, and adjusts a few braces in
ScalaRuntime.scala so the patch srt.scala (used by that script)
is shorter.
We should really avoid checking in the products of that script and
run it as part of the build, or, better, use the bytecode
instrumentation framework instead of a modified standard library.
But I have to leave that for another day.
|
| | | |/ / /
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Not every application will force these in a single thread; we
have to do our best to avoid cycles between them.
The enclosed test was failing every time before the change.
This commit breaks the cycle by avoiding computing `tupleNames`
in the constructor of `ScalaRuntime`. The new version has the
added benefit of including specialized tuple subclasses, which
is verified with a unit test for `isTuple`.
Are there more of these lurking? It seems likely. I'm more than
a little concerned about the way the `ControlThrowable` fires up
`scala.SystemProperties` to check whether or not to suppress
stack traces; there is already an ugly hack in place:
object NoStackTrace {
final def noSuppression = _noSuppression
// two-stage init to make checkinit happy,
// since sys.SystemProperties.noTraceSupression.value
// calls back into NoStackTrace.noSuppression
final private var _noSuppression = false
_noSuppression = sys.SystemProperties.noTraceSupression.value
}
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7801 Fix a nightmarish bug in Symbols#adaptInfos
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The compiler-in-residence has always been a sketchy affair;
FSC and REPL offers a bounty of bugs that exploit the menagerie
of time-travel mechanisms in play for symbols' metadata (type, flags,
name and owner.) but are often cleverly masked by optimizations in
the compiler based on reference equality.
The latest: an innocuous change in Erasure:
https://github.com/scala/scala/commit/d8b96bb8#commitcomment-3995163
means that some `ErasureMap`-s over `MethodType`-s are now true
identities (as `UnitTpe` is always the same object, whereas
`erasedTypeRef(UnitClass)` returns an different `TypeRef` each
time.)
This, in turn, enables `TypeMap#mapOver` to reuse
the existing enclosing type, and so on. On such subtleties hinge
further optimizations, such as whether or not a given phase's
`InfoTransformer` needs to add an entry in a symbols type history.
When the REPL (or FSC / Presentation Compiler) creates a new
`Run`, `Symbol#rawInfo` tries to adapt the entries in the type
history for the new run. For packages, this was taken to be a
no-op; each entry is marked as being valid in the new run and
no further action is taken. This logic lurks in `adaptInfos`.
But, when the namer enters a new symbol in a package, it
*mutates* the Scope of that package classes info `enteringTyper`.
So the later entries in the type history *must* be invalidated
and recomputed.
We have two choices for a fix:
1) modify `Namers#enterInScope` to blow away the subsequent
type history for the owning symbol after inserting the
new member. Something like `owner.setInfo(owner.info)` would
have the desired effect.
2) Change `adaptInfos` to be more conservative when it comes
to package classes, and retain only the oldest entry in the
type history.
This commit goes for option 2.
|
| |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Foo.this.x and Foo.super.x were roughly unrelated in the eyes
of isSubType. I implemented conformance as described in the comment:
This is looking for situations such as B.this.x.type <:< B.super.x.type.
If it's a ThisType on the lhs and a SuperType on the right, and they originate
in the same class, and the 'x' in the ThisType has in its override chain
the 'x' in the SuperType, then the types conform.
I think this is overly conservative but it's way ahead of
where it was.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Topic/patmat inference prep
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Don't suggest "_: <none>" as an alternative when the pattern
type doesn't conform to the expected type.
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
Various bugfixes and improvements for the quasiquotes
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Syntax spec mislead me to believe that annotation can't have type
parameters or multiple argument lists... I guess the lesson here is
don't trust the spec.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
1. blocks now match single term-level expressions to account for
automatic block elimination. E.g.
val q"{ ..$stats }" = q"foo"
will match into stats = List(q"foo"). This is useful to uniformly
deal with blocks on term level.
2. blocks in quasiquotes collapse into single expressions
3. Applied and TypeApplied now have constructors too which helps
to unify matching and extraction in quasiquote reifier
4. TypeApplied now matches AppliedTypeTree too
5. Add Syntactic prefix to Applied and TypeApplied
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7810 Reflect private constructor
|
| | |_|/ / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
`JavaMirror.constructorToJava` uses `getDeclaredConstructor` now
instead of `getConstructor`.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Noise reduction + minor enhance in TreeCheckers.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Misc irrelevant work, which I can only offer as-is. It lowers
the noise in -Ycheck:* output and performs some common sense
chillaxes like not screaming ERROR IN INTERNAL CHECKING! WE'RE
ALL GOING TO DIE! when a tree doesn't hit all nine points at
the Jiffy Tree.
You can see some reasonably well reduced symbol flailing if
you run the included pending tests:
test/partest --show-diff test/pending/pos/treecheckers
Example output,
Out of scope symbol reference {
tree TypeTree Factory[Traversable]
position OffsetPosition test/pending/pos/treecheckers/c5.scala:3
with sym ClassSymbol Factory: Factory[CC]
and tpe ClassArgsTypeRef Factory[Traversable]
encl(1) ModuleSymbol object Test5
ref to AbstractTypeSymbol X (<deferred> <param>)
}
|
|\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | | |
SI-7817 Fix regression in structural types
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Calls to structural types are converted to reflective calls
in the `cleanup` phase, which, along with `mixin`, does its work
after `flatten`.
`Symbol#owner` behaves in a phase dependent manner; after flatten
the owner of lifted class is given as the enclosing package.
Except when they're not.
`ModuleSymbol`s representing an object nested inside a class
are viewed dually as modules *and* methods (see the comments on
`isModuleNotMethod` for some background). When it comes time to
flatten, we're presented with a quandary: the method must clearly
stay owned by the enclosing class, but surely the lifted module
should be owned by the enclosing package, to have the same owner
as its associated module class.
The `method` nature of this symbol seems to win:
override def owner = {
if (Statistics.hotEnabled) Statistics.incCounter(ownerCount)
if (!isMethod && needsFlatClasses) rawowner.owner
else rawowner
This wrinkle leads to a wrong turn in `TreeGen#mkAttributedRef`,
which incorrectly rewrites `REF(O)` to `p1.`package`.O`. It seems
this problem has gone unnoticed because the tree emitted referred
to a static symbol (the reflection cache for structural types),
and the backend simply elided the qualifier `p1.package`.
A recent change to the backend makes it more conservative about
dropping qualifiers on the floor, and it started emitting a reference
to a package object that doesn't exist.
This commit despairingly checks `isDefinedInPackage` of both the
module *and* the module class. The test cases from the previous
commit illustrated the status quo, and this commit updates the
joint compilation test with the bug fix. A new test is to show that
the symptom (structural type crash) is now fixed.
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
To `package`, or not `package`, that is the question.
This lines marked with !!! get this wrong, and be remedied
by the next commit.
This problem is culpable for the crash in the enclosed `pending` test.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Eliminate TypeTrees with null original.
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This is a retry of #2801 after figuring out the range position
error. Should there be anyone out there who compiles with -Xdev,
know that this commit eliminates the 1406 errors one presently
incurs compiling src/library.
A val declared in source code receives only one tree from the
parser, but two are needed - one for the field and one for the
getter. I discovered long ago that if the val had an existential
type, this was creating issues with incompatible existentials
between the field and the getter. However the remedy for that
did not take into account the whole of the wide range of super
subtle issues which accompany tree duplication.
In particular, the duplicated tree must be given not only a
fresh TypeTree(), but that TypeTree cannot share the same
original without running afoul of range position invariants.
That's because typedTypeTree resurrects the original tree with
whatever position it has - so the "original" needs to be a
duplicate of the original with a focused position.
Should the call to TypeTree.duplicate also duplicate the original?
I think so, but I bequeath this question to others.
This commit also eliminated some duplicate error messages, because
duplicate suppression depends on the errors having the same position.
See c478eb770d, 7a6fa80937 for previous related work.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7791 Line number table reflects underlying file
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Since positions ultimately know their ultimate
positions in their ultimate source, use that line
number, ultimately, when emitting line number
table entries.
It is possible, but possibly not useful, to emit
both the actual (ultimate) line number and the
nominal one.
The `int`-valued line number of the `StackTraceElement`
is "derived" from the attribute.
In global, wrapping a `BatchSourceFile` as a
`ScriptSource` happens in `compileSources` to
facilitate testing.
A `ScriptTest` facility is provided to facilitate
testing the script facility. It is rather facile.
|