| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
SI-6169 Refine java wildcard bounds using corresponding tparam
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also fixes part of SI-8197. Necessary complement to SI-1786 (#2518),
because we now infer tighter bounds for RHSs to conform to.
When opening an existential, Java puts constraints in the typing environment
that are derived from the bounds on the type parameters of the existentially
quantified type, so let's do the same for existentials over java-defined
classes in skolemizeExistential...
Example from test case:
```
public class Exist<T extends String> {
// java helpfully re-interprets Exist<?> as Exist<? extends String>
public Exist<?> foo() { throw new RuntimeException(); }
}
```
In Scala syntax, given a java-defined `class C[T <: String]`, the
existential type `C[_]` is improved to `C[_ <: String]` before skolemization,
which models what Java does (track the bounds as type constraints in the typing environment)
(Also tried doing this once during class file parsing or
when creating the existential type, but that causes cyclic errors
because it happens too early.)
|
|\ \
| | |
| | | |
SI-8237 Avoid cyclic constraints when inferring hk type args
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
An `AppliedTypeVars` spawned from `HKTypeVar#applyArgs`
(necessarily) shares the same `TypeConstraints`.
But, we can have multiple ATVs based on a single HKTV floating
around during inference, and they can appear on both sides
of type relations. An example of this is traced out in
the enclosed test.
This commit avoids registering upper/lower bound constraints
when this is detected.
In the enclosed test, we end up with an empty set of constraints
for `?E`, which results in inference of Nothing, which is what
we expect.
I have also improved the printing of ATVs (to include the args)
and sharpened the log message when `solve` leaves type variables
instantiated to `NoType`, rather than some other type that doesn't
conform to the bounds. Both of these changes helped me to get
to the bottom of this ticket. The improved `ATV#toString` shows
up in some updated checkfiles.
The reported test has quite a checkered history:
- in 2.10.0 it worked, but more by good luck than good planning
- after the fix for SI-7226 / 221f52757aa6, it started crashing
- from 3bd897ba0054f (a merge from 2.10.x just before 2.11.0-M1)
we started getting a type inference failure, rather than a crash.
"no type parameters for method exists [...] because cyclic
instantiation".
- It still crashes in `isGround` in 2.10.3.
|
|\ \ \
| | | |
| | | | |
SI-8245 Fix regression in interplay between lazy val, return
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In 4c86dbbc492 / SI-6358, synthesis of lazy val accessors trees was
moved into the typer phase (in MethodSynthesis). Before that point,
the symobl for the accessor *was* created early, but the tree was
not. This led to crashes in intervening phases (extensionmethods)
as `changeOwner` calls didn't catch the smuggled symbol.
Moving the accessor generation forward, however, brought a problem:
we now introduce a DefDef around the RHS of the lazy val, but we're
not actually guaranteed that the body has already been typechecked.
If it happened to be typechecked for the purposes of return type
inference, we'll pick up the typechecked tree from `transformed`:
// LazyValGetter#derivedTree
val rhs1 = transformed.getOrElse(rhs0, rhs0)
But if the method had an explicit return type (which must *always*
be the case if it contains a `return`!), `rhs0` will be untyped.
This leads to, e.g.:
def foo(o: Option[Int]): Int = {
lazy val i = o.getOrElse(return -1)
i + 1
}
def foo(o: Option[Int]): Int = {
lazy <artifact> var i$lzy: Int = _;
<stable> <accessor> lazy def i: Int = {
i$lzy = o.getOrElse(return -1);
i$lzy
};
i.+(1)
};
When this is typechecked, the `return` binds to the closest enclosing
`DefDef`, `lazy def i`. This commit changes `Context#enclMethod` to
treat `DefDef`s as transparent.
`enclMethod` is only used in one other spot that enforces the
implementation restriction that "module extending its companion class
cannot use default constructor arguments".
|
|\ \ \
| | | |
| | | | |
AnyRefMap iterates its way to ((null, null))
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Changed logic to prevent mutation between hasNext and next from delivering invalid results.
Also fixed superscripts in scaladoc.
|
|\ \ \ \
| |/ / /
|/| | | |
kills resetAllAttrs
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Now when resetAllAttrs is gone, we can use a shorter name for the one
and only resetLocalAttrs.
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit removes resetAllAttrs from the public reflection API.
This method was previously deprecated, but on a second thought that
doesn't do it justice. People should be aware that resetAllAttrs is just
wrong, and if they have code that uses it, this code should be rewritten
immediately without beating around the bush with deprecations. There's
a source-compatible way of achieving that (resetLocalAttrs), so that
shouldn't bring much trouble.
Secondly, resetAllAttrs in compiler internals becomes deprecated. In subsequent
commits I'm going to rewrite the only two locations in the compiler that
uses it, and then I think we can remove it from the compiler as well.
|
|\ \ \
| | | |
| | | | |
SI-8092 More verify for f-interpolator
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A denshish refactor makes the FormatInterpolator a nice bundle
that destructures its input and flattens out the classes to
give the code some elbow room. Everything shifts left.
The `checkType` method is refolded and renamed `pickAcceptable`.
An additional test case captures the leading edge test, that
a % should follow a hole, and which is the most basic
requirement.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Attempt to verify the nooks and crannies of the format string.
Allows all syntax in the javadoc, including arg indexes. If the
specifier after an arg has an index that doesn't refer to the arg,
a warning is issued and the missing `%s` is prepended (just as
for a part with a leading `%n`).
Other enhancements include detecting that a `Formattable` wasn't
supplied to `%#s`.
Error messages attempt to be pithy but descriptive.
|
|\ \ \ \
| | | | |
| | | | | |
SI-8131 fixes residual race condition in runtime reflection
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Apparently some completers can call setInfo while they’re not yet done,
which resets the LOCKED flag, and makes anything that uses LOCKED to
track completion unreliable. Unfortunately, that’s exactly the mechanism
that was used by runtime reflection to elide locking for symbols that are
known to be initialized.
This commit fixes the problematic lock elision strategy by introducing
an explicit communication channel between SynchronizedSymbol’s and their
completers. Now instead of trying hard to infer whether it’s already
initialized or not, every symbol gets a volatile field that can be queried
to provide necessary information.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Depending on the environment in which the test is run, s1 can be either
“String” or “java.lang.String”. This is one of the known non-deterministic
behaviors of our reflection, caused by prefix stripping only working for
packages defined in the root mirror. Until we fix this, I suggest we make
the test more lenient.
|
| | | | | |
|
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Such representation codifies the fact that type tree that doesn't have
embedded syntactic equivalent must have been inferred or otherwise
provided by the compiler rather than specified by the end user.
Additionally it also ensures that we can still match trees without
explicit types (e.g. vals without type) after typechecking. Otherwise
the same quote couldn't be used in situations like:
val q"val x = 42" = typecheck(q"val x = 42")
|
|\ \ \ \
| | | | |
| | | | | |
Fix inconsistent binding in patterns with 10+ holes
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously a map that was storing bindings of fresh hole variables with
their contents (tree & cardinality) used to be a SortedMap which had
issues with inconsistent key ordering:
"$fresh$prefix$1" < "$fresh$prefix$2"
...
"$fresh$prefix$8" < "$fresh$prefix$9"
"$fresh$prefix$9" > "$fresh$prefix$10"
This issue is solved by using a LinkedHashMap instead (keys are inserted
in the proper order.)
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix feature warnings in test.osgi.comp
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Reduces the amount of noise from 22 lines down to the actually
interesting 5 lines of information.
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
SI-8173 add support for patterns like init :+ last to quasiquotes
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Adds support for patterns like:
val q"{ ..$init; $last }" = q"{ a; b; c }"
// init == List(q"a", q"b")
// last == q"c"
Which under the hood get compiled as `:+` patterns:
SyntacticBlock(init :+ last)
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8228 Avoid infinite loop with erroneous code, overloading
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
`isApplicableBasedOnArity` couldn't get of the ferris wheel after
as `followApply` kept insisting on another spin.
scala> ErrorType nonPrivateMember nme.apply
res0: $r.intp.global.Symbol = value apply
scala> res0.info
res1: $r.intp.global.Type = <error>
This commit makes `followApply` consider that an `ErrorType`
does not contain an `apply` member.
I also considered whether to do a deep check on the type
(`isErroneous`), but I can't motivate this with a test.
I tend to think we *shouldn't* do that: `List[${ErrorType}]`
still has an `apply` member that we should follow, right?
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-4997 deprecate StringLike.linesIterator for StringLike.lines
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | | |
Deprecated. lines is by far more consistent with the rest of the naming in the library.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8233 Fix regression in backend with boxed nulls
|
| | |_|_|_|_|/
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Regressed in SI-7015 / 1b6661b8.
We do need to "unbox" the null (ie, drop a stack from and load
a null) in general. The only time we can avoid this is if the
tree we are adapting is a `Constant(Literal(null))`.
I've added a test for both backends. Only GenICode exhibited
the problem.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8170 Fix regression in TypeRef#transform w. PolyTypes
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Regressed in SI-8046 / edc9edb7, by my hand.
At the time, I noticed the problem: transform wasn't accounting
for the potential Poly-Type-ness of its argument, and this would
lead to under-substituted types. The commit comment of edc9edb7
shows an example.
But the remedy wasn't the right one. The root problem is
that a TypeMap over a PolyType can return one with cloned
type parameter symbols, which means we've lose the ability
to substitute the type arguments into the result.
This commit detects up front whether the type-under-transform
is a PolyType with the current TypeRef's type parameters, and
just runs the `asSeenFrom` over its result type.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
PR #3233 cleanup
|
| | |/ / / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
- `::.head` became a `val`; excessive accessor removed
- SerializationProxy moved to `object List`
|
|/ / / / / / / |
|
| |_|_|/ / /
|/| | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7322 Interpolator idents must be encoded
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Otherwise, they are not found.
This matters for term names with a differential encoding.
Footnote, normally ident() encodes, but INTERPOLATIONID
is !isIdent, so that is not used here. Maybe that would
be the better improvement.
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
SI-7124 make macro definitions prettier in scaladoc
|
| | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Macros are now prettier in scaladoc, by
- hiding the `macroImpl` annotation
- showing the `macro` modifier in front
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7700 @unspecialized, Part Deux: Now Working.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This annotation was introduced to allow us to mark methods within
a specialized trait as immune from specialization. In particular,
this is desirable for `Function1.{andThen, compose}`.
However, it seems we need to check for this in two places in the
specialization code base. The feature is now backed with a test.
|
|\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | | |
SI-8143 Regressions with override checks, private members
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
These regressed in e609f1f20b, which excluded all private methods from
overriding checks. We should only exclude private[this] members on the
low end of a pair, as was done before that commit, and, we must also
exclude private members on the high side.
Why? Warning: reverse engineered intuition follows.
We need to report an error when if a private method in a subclass
has matches a less-private method in the super class and report an
error, lest the user be fooled into thinking it might be invoked
virtually. On the other hand, adding a private method to a super
class shouldn't invalidate the choice names of public members in
its superclasses.
I've removed the test case added by that commit and will lodge a
reworked version of it that Paul provided as a new issue. That shows
a bug with qualified private + inheritance.
In addition, the expectation of `neg/accesses.check` is reverted
to its 2.10.3 version, which I believe is correct. When it was
changed in e609f1f20b it sprouted a variation, `neg/accesses-2`,
which has now changed behaviour. The intent of that test will
be captured in the aforementioned issue covering qualified private
inheritance.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8213 AnyRefMap.getOrElseUpdate is faulty
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Altered getOrElseUpdate to be robust to the map changing out from under it as a result of calling the default value method. Side-effects FTW!
Made a comparable change in LongMap also, as it was also affected. And added a test to SetMapConsistencyTest.
|
|\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | | |
Prohibit views targeting AnyVal
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Library changes in Scala 2.10 mean that we are left with the
unfortunate situation of admitting:
scala> "": AnyVal
res0: AnyVal =
We already have explicit checks in place to prevent views
targeting `AnyRef`. This commit balances this out by prohibiting
`AnyVal`, as well.
The enclosed test shows that this case is now prevented. If multiple
implicits views are applicable, the ambiguity error is still raised;
these check comes right at the end. Maybe that ought to be changed,
but I don't think it matters too much.
I've also disabled this prohibition under -Xsource:2.10.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
More penance. Extend the unit test and don't include CR
in the line text.
This is obvious, which shows how dangerous it is to refactor
without unit tests.
My very favorite bugs are off-by-one and EOL handling, followed
closely by off-by-Int.MaxValue.
|