| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Add an extremely well-commented test
|
| | |
| |
| |
| |
| |
| |
| | |
This commit includes a test for some simple existential subtyping
checks. It is exceptionally well-commented and may be helpful to
someone trying to figure out what the rules are (supposed to be)
in the future.
|
| |\ \
| |/
|/| |
SI-8283 mutation-free bound inference for existentials
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
A safer version of the fix for SI-6169 (#3471)
Only modify the skolems to avoid leaking the sharper bounds to `quantified`.
The included test case was minimized from akka-camel
(src/main/scala/akka/camel/Consumer.scala).
|
| |\ \
| | |
| | | |
SI-8188 NPE during deserialization of TrieMap
|
| | | |
| | |
| | |
| | | |
The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
|
| |\ \ \
| | | |
| | | | |
SI-6632 ListBuffer's updated accepts negative positions
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
Changed the behavior in SeqLike.updated (which would silently accept negatives and throw on empty.tail) to throw IndexOutOfBoundException.
Updated tests to verify the behavior in ListBuffer. Everything else SeqLike will come along for the ride.
|
| |\ \ \
| | | |
| | | | |
SI-8177 specializeSym must use memberInfo on high side
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When determining whether member `symLo` of `tpLo`
has a stronger type than member `symHi` of `tpHi`,
should we use memberType or memberInfo?
Well, memberType transforms (using `asSeenFrom`) `sym.tpe`,
whereas memberInfo performs the same transform on `sym.info`.
For term symbols, this ends up being the same thing (`sym.tpe == sym.info`).
For type symbols, however, the `.info` of an abstract type member
is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol,
so that `sym.tpe <:< sym.info`, but not the other way around.
Thus, for the strongest (correct) result,
we should use `memberType` on the low side.
On the high side, we should use the result appropriate
for the right side of the `<:<` above (`memberInfo`).
I also optimized the method a little bit by avoiding calling memberType
if the symbol on the high side isn't eligble (e.g., it's a class).
PS: I had to add a workaround to reifyType, because
we now dealias a little less eagerly, which means
a type selection on refinement class symbols makes it to reify
this broke the t8104 tests.
I also had to update the run/t6992 test, which should now test the right thing.
Tests should be commented and/or use sensible names.
What is it testing? What is the expected outcome? We should not be left guessing.
|
| |\ \ \
| |_|/
|/| | |
SI-8153 Mutation is hard, let's go shopping with an empty list
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Changed the implementation of iterator to be more robust to mutation of the underlying ListBuffer.
Added a test to make sure bug is gone.
Fixed an "unsafe" usage of ListBuffer.iterator in the compiler, and added a comment explaining the (new) policy for iterating over a changing ListBuffer.
The compiler now uses a synchronized-wrapped ArrayBuffer instead of ListBuffer, as that makes the (custom) units Iterator more natural to write (and avoids O(n) lookups).
|
| |\ \ \
| | | |
| | | | |
SI-8276 Test for cyclic error caused by (reverted) SI-1786 fix
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We reverted SI-1786 recently on the grounds that its means of
avoiding cycles (not sharpening bounds of T[_] when T is
uninitialized) caused unacceptable non-determinism (well:
compilation order dependency) to type inference.
Nary a day later, @gkossakowski hit a regression in scala-io.
Bisection revealed that it stopped working in 2dbd17a2 and
started working agiain after the revert. How's that for
prescience!
I've distilled the cyclic error in scala-io in this test
case.
I'm yet to pinpoint this, followon error, which didn't survive
the shrink ray, and only appeared in the original code:
error: java.lang.IndexOutOfBoundsException: 0
at scala.collection.LinearSeqOptimized$class.apply(LinearSeqOptimized.scala:51)
at scala.collection.immutable.List.apply(List.scala:83)
at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.correspondingTypeArgument(TypeMaps.scala:5
|
| |\ \ \
| |/ /
|/| | |
SI-8280 regression in implicit selection.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 2fa2db7840 I fixed a bug where applicable implicit conversions
would not be found for numeric types if one introduced any aliasing
or singleton types, for the usual reasons involving the absence of
uniform type normalization. See pos/t7228 for examples - that test
case has 20 errors in 2.10.3 but compiles in master.
An unintended side effect was making implicit search less oblivious.
It turns out that in so doing I had created ambiguity where there was
none before. Not because it was any more ambiguous, but because the
compiler now had the wits to notice the ambiguity at an earlier time.
The fix for this is not intuitive. The way the internal logic is,
we need to keep the wool over implicit search's eyes, which leads
to those unrecognized types being passed to adapt, where they are
recognized and weak subtyping suffices to be more specific. It is
sufficient for SI-7228 that weak subtyping be done correctly - the
other change, which is reverted here, was exposing the type arguments
of Function1 when a view exists as a subtype of Function1.
It is also possible this could be remedied by calling weak_<:<
somewhere which is presently <:<, but I don't know where and it
has a far greater chance of affecting something else than does
this, which is a straight reversion of a post-2.10.3 change.
|
| |\ \
| | |
| | | |
SI-8134 SI-5954 Fix companions in package object under separate comp.
|
| | | |
| | |
| | |
| | | |
Aesthetics only.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As the prophet once said:
"'Tis better to never do at all than to have do and undo"
Let's try that in 2.12.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I noticed that the pos/5954d was tripping a println "assertion".
This stemmed from an inconsistency between
`TypeRef#{parents, baseTypeSeq}` for a package objects compiled
from source that also has a class file from a previous compilation
run.
I've elevated the println to a devWarning, and changed
`updatePosFlags`, the home of this evil symbol overwriting,
to invalidate the caches in the symbols info. Yuck.
I believe that this symptom is peculiar to package objects because
of the way that the completer for packages calls `parents` during
the Namer phase for package objects, before we switch the symbol
to represent the package-object-from-source. But it seems prudent
to defensively invalidate the caches for any symbol that finds its
way into `updatePosFlags`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The tests cases enclosed exhibited two failures modes under
separate compilation.
1. When a synthetic companion object for a case- or implicit-class
defined in a package object is called for,
`Namer#ensureCompanionObject` is used to check for an explicitly
defined companion before decided to create a synthetic one.
This lookup of an existing companion symbol by `companionObjectOf`
would locate a symbol backed by a class file which was in the
scope of the enclosing package class. Furthermore, because the
owner of that symbol is the package object class that has now
been noted as corresponding to a source file in the current
run, the class-file backed module symbol is *also* deemed to
be from the current run. (This logic is in `Run#compiles`.)
Thinking the companion module already existed, no synthetic
module was created, which would lead to a crash in extension
methods, which needs to add methods to it.
2. In cases when the code explicitly contains the companion pair,
we still ran into problems in the backend whereby the class-file
based and source-file based symbols for the module ended up in
the same scope (of the package class). This tripped an assertion
in `Symbol#companionModule`.
We get into these problems because of the eager manner in which
class-file based package object are opened in `openPackageModule`.
The members of the module are copied into the scope of the enclosing
package:
scala> ScalaPackage.info.member(nme.List)
res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462
scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List)
res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462
This seems to require a two-pronged defense:
1. When we attach a pre-existing symbol for a package object symbol
to the tree of its new source, unlink the "forwarder" symbols
(its decls from the enclosing
package class.
2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`,
remove static member modules from the scope of the enclosing
package object (aka `exitingFlatten(nestedModule.owner)`).
This commit also removes the warnings about defining companions
in package objects and converts those neg tests to pos (with
-Xfatal-warnings to prove they are warning free.)
Defining nested classes/objects in package objects still has
a drawback: you can't shift a class from the package to the
package object, or vice versa, in a binary compatible manner,
because of the `package$` prefix on the flattened name of
nested classes. For this reason, the `-Xlint` warning about
this remains. This issue is tracked as SI-4344.
However, if one heeds this warning and incrementatlly recompiles,
we no longer need to run into a DoubleDefinition error (which
was dressed up with a more specific diagnostic in SI-5760.)
The neg test case for that bug has been converted to a pos.
|
| |\ \ \
| | | |
| | | | |
Fix pattern inference regression
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit does not close SI-5900. It only addresses a regression
in 2.11 prereleases caused by SI-7886.
The fix for SI-7886 was incomplete (as shown by the last commit)
and incorrect (as shown by the regression in pos/t5900a.scala and
the fact it ended up inferring type parameters.)
I believe that the key to fixing this problem will be unifying
the inference of case class constructor patterns and extractor
patterns.
I've explored that idea:
https://gist.github.com/retronym/7704153
https://github.com/retronym/scala/compare/ticket/5900
But didn't quite get there.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
qbin/scalac test/pending/neg/t7886b.scala && qbin/scala Test
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
at Test$$anon$1.accept(t7886b.scala:15)
at Test$.g(t7886b.scala:9)
|
| |\ \ \
| | | |
| | | | |
SI-8244 Fix raw type regression under separate compilation
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In #1901, handling of raw types encountered in signatures during class
file parsing was changed to work in the same manner as
`classExistentialType`, by using
`existentialAbstraction(cls.tparms, cls.tpe_*)`
But this never creates fresh existential symbols, and just sticks
the class type parameters it `quantified`:
scala> trait T[A <: String]
defined trait T
scala> val cls = typeOf[T[_]].typeSymbol
cls = trait T#101864
scala> cls.typeParams
res0 = List(type A#101865)
scala> cls.tpe_*
res1 = T#101864[A#101865]
scala> classExistentialType(cls)
res3 = T#101864[_ <: String#7209]
scala> val ExistentialType(quantified, result) = res3
List(type A#101865)
In the enclosed test case, this class type parameter was substituted
during `typeOf[X] memberType sym`, which led us unsoundly thinking
that `Raw[_]` was `Raw[X]`.
I've added a TODO comment to review the other usages of
`classExistentialType`.
Test variations include joint and separate compilation, and the
corresponding Scala-only code. All fail with type errors now,
as we expect. I've also added a distillation of a bootstrap
error that failed when I forgot to wrap the `existentialType`.
|
| |\ \ \
| |/ /
|/| | |
SI-7753 InstantiateDependentMap narrows type of unstable args
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[Most of this comment and the initial fix were implemented by Jason Zaugg.
I just cleaned it up a bit.]
After a soundness fix in SI-3873, instantiation of dependent
method type results behaved differently depending on whether the argument
from which we were propagating information had a stable type
or not. This is particular to substitution into singleton types
over the parameter in question.
If the argument was stable, it was substituted into singleton
types, such as the one below in the prefix in `a.type#B`
(which is the longhand version of `a.B`)
scala> class A { type B >: Null <: AnyRef }
defined class A
scala> object AA extends A { type B = String }
defined object AA
scala> def foo(a: A): a.B = null
foo: (a: A)a.B
scala> foo(AA)
res0: AA.B = null
But what if it isn't stable?
scala> foo({def a = AA; a: A { type B <: String}})
res1: a.B = null
This commit changes that to:
scala> foo({def a = AA; a: A { type B <: String}})
res1: A{type B <: String}#B = null
|
| |\ \
| | |
| | | |
SI-8177 co-evolve more than just RefinedTypes
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We look for any prefix that has a refinement class for a type symbol.
This includes ThisTypes, which were not considered before.
pos/t8177g.scala, neg/t0764*scala now compile, as they should
Additional test cases contributed by Jason & Paul.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`asSeenFrom` produced a typeref of the shape `T'#A` where `A` referred to a symbol
defined in a `T` of times past.
More precisely, the `TypeRef` case of `TypeMap`'s `mapOver` correctly modified a prefix
from having an underlying type of `{ type A = AIn }` to `{ type A = Int }`,
with a new symbol for `A` (now with info `Int`), but the symbol in the outer
`TypeRef` wasn't co-evolved (so it still referred to the `A` in `{ type A = AIn }`
underlying the old prefix).
`coEvolveSym` used to only look at prefixes that were directly `RefinedType`s,
but this bug shows they could also be `SingleType`s with an underlying `RefinedType`.
|
| |\ \ \
| | | |
| | | | |
A test case for a name binding progression
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I noticed the change when adapting Slick to work with
Scala 2.11 in `AbstractSourceCodeGenerator.scala`.
The behaviour changed in a70c8219.
This commit locks down the new, correct behaviour with a test.
|
| |\ \ \ \
| |_|/ /
|/| | | |
Avoid SOE in logicallyEnclosingMember
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We've started calling this method during higher-kinded subtyping
to ensure that variances of higher order type params in overriding
as soundly aligned.
Turns out that running this over the expansion of the SBT task
macro leads to a SOE due to a corrupt owner chain.
I've fixed that in SBT (https://github.com/sbt/sbt/pull/1113),
but we ought not crash like this.
This commit considers NoSymbol to be its own enclosing member and
logs a -Xdev warning. This is analagous to the handling of
`NoSymbol.owner`.
|
| |\ \ \ \
| |_|/ /
|/| | | |
SI-6736 Range.contains is wrong
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Operations are reasonable when they don't require indexing or conversion into a collection. These include head, tail, init, last, drop, take, dropWhile, takeWhile, dropRight, takeRight, span.
Tests added also to verify the new behavior.
|
| | | | |
| | | |
| | | |
| | | | |
Removed once-used private method that was calculating ranges in error and corrected the contains method (plus improved performance).
|
| |\ \ \ \
| | | | |
| | | | | |
private vals in traits depend on composition order
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix for SI-7475 in #3440 took care of this one.
I nixed the old (redundant) test cases and replaced by a single run/ test,
which didn't compile until.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-7475 Private members aren't inheritable, findMember overhaul
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- comment the cases in `isNewMember`
- check both sides for privacy (doesn't influence behaviour of
any tests, but it means that method can be understood without
understanding the order of traversal of members.)
- hoist `findAll`
- break out of the loop in `FindMembers` as soon as we determine
that the candidate member is matched by an already-found member
and can be discarded.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It turns out `findMembers` has been a bit sloppy in recent
years and has returned private members from *anywhere* up the
base class sequence. Access checks usually pick up the slack
and eliminate the unwanted privates.
But, in concert with the "concrete beats abstract" rule in
`findMember`, the following mishap appeared:
scala> :paste
// Entering paste mode (ctrl-D to finish)
trait T { def a: Int }
trait B { private def a: Int = 0 }
trait C extends T with B { a }
// Exiting paste mode, now interpreting.
<console>:9: error: method a in trait B cannot be accessed in C
trait C extends T with B { a }
^
I noticed this when compiling Akka against JDK 8; a new private method
in the bowels of the JDK was enough to break the build!
It turns out that some finesse in needed to interpret SLS 5.2:
> The private modifier can be used with any definition or declaration
> in a template. They are not inherited by subclasses [...]
So, can we simply exclude privates from all but the first base class?
No, as that might be a refinement class! The following must be
allowed:
trait A { private def foo = 0; trait T { self: A => this.foo } }
This commit:
- tracks when the walk up the base class sequence passes the
first non-refinement class, and excludes private members
- ... except, if we are at a direct parent of a refinement
class itself
- Makes a corresponding change to OverridingPairs, to only consider
private members if they are owned by the `base` Symbol under
consideration. We don't need to deal with the subtleties of
refinements there as that code is only used for bona-fide classes.
- replaces use of `hasTransOwner` when considering whether a
private[this] symbol is a member.
The last condition was not grounded in the spec at all. The change
is visible in cases like:
// Old
scala> trait A { private[this] val x = 0; class B extends A { this.x } }
<console>:7: error: value x in trait A cannot be accessed in A.this.B
trait A { private[this] val x = 0; class B extends A { this.x } }
^
// New
scala> trait A { private[this] val x = 0; class B extends A { this.x } }
<console>:8: error: value x is not a member of A.this.B
trait A { private[this] val x = 0; class B extends A { this.x } }
^
Furthermore, we no longer give a `private[this]` member a free pass
if it is sourced from the very first base class.
trait Cake extends Slice {
private[this] val bippy = ()
}
trait Slice { self: Cake =>
bippy // BCS: Cake, Slice, AnyRef, Any
}
The different handling between `private` and `private[this]`
still seems a bit dubious.
The spec says:
> An different form of qualification is private[this]. A member M
> marked with this modifier can be accessed only from within the
> object in which it is defined. That is, a selection p.M is only
> legal if the prefix is this or O.this, for some class O enclosing
> the reference. In addition, the restrictions for unqualified
> private apply.
This sounds like a question of access, not membership. If so, we
should admit `private[this]` members from parents of refined types
in `FindMember`.
AFAICT, not too much rests on the distinction: do we get a
"no such member", or "member foo inaccessible" error? I welcome
scrutinee of the checkfile of `neg/t7475f.scala` to help put
this last piece into the puzzle.
One more thing: findMember does not have *any* code the corresponds
to the last sentence of:
> SLS 5.2 The modifier can be qualified with an identifier C
> (e.g. private[C]) that must denote a class or package enclosing
> the definition. Members labeled with such a modifier are accessible
> respectively only from code inside the package C or only from code
> inside the class C and its companion module (ยง5.4).
> Such members are also inherited only from templates inside C.
When I showed Martin this, he suggested it was an error in the
spec, and we should leave the access checking to callers of
that inherited qualified-private member.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:
d905558 Variation #10 to optimze findMember
fcb0c01 Attempt #9 to opimize findMember.
71d2ceb Attempt #8 to opimize findMember.
77e5692 Attempty #7 to optimize findMember
275115e Fixing problem that caused fingerprints to fail in
e94252e Attemmpt #6 to optimize findMember
73e61b8 Attempt #5 to optimize findMember.
04f0b65 Attempt #4 to optimize findMember
0e3c70f Attempt #3 to optimize findMember
41f4497 Attempt #2 to optimize findMember
1a73aa0 Attempt #1 to optimize findMember
This didn't actually bear fruit, and the intervening years have
seen the implementations drift.
Now is the time to reunite them under the banner of `FindMemberBase`.
Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.
While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.
Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.
Coming up next: we can actually fix SI-7475!
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This affords us:
- a better chance to share code with `findMembers` again
- the ability to break up the logic into smaller methods for
scrutability and JIT-tability.
The cost is the use of the heap rather than the stack for the
working area of the computation. But I didn't notice a difference
between `locker.lib` and `quick.lib` after this change.
I've left the old implementation in place with an assertion to
verify identical results. In the next commit, this stepping stone
will be removed, and we'll update `findMembers` to share the code.
Some problem areas have been highlighted and will be addressed
after the refactoring phase is complete.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Revert "SI-1786 incorporate defined bounds in inference"
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Have to revert because the stricter bounds that it inferred break e.g., slick.
(Backstop for that added as pos/t1786-counter.scala, as minimized by Jason)
Worse, the fix was compilation order-dependent.
There's a less invasive fix (SI-6169) that could be generalized
in `sharpenQuantifierBounds` (used in `skolemizeExistential`),
but I'd rather not mess with existentials at this point.
This reverts commit e28c3edda4dd405ed382227d2a688b799bf33c72.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
test/files/pos/t1786.scala
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-5994 battling implicits for String.lines
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Deprecated ProcessBuilder's lines method and renamed it lineStream.
stream was another possibility, but that seemed more likely to cause conflicts.
streaming was also tried, but feedback was in favor of lineStream.
Also updated tutorial in ProcessBuilder.
I am sure this will break some tests, but because of the name conflict it's hard to be sure where they are. So Jenkins gets to find the problems for me.
Changed name to lineStream.
|
