| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| | |
SI-8197 clarify overloading resolution with default args
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit was co-authored with Lukas. His analysis is below.
If there are multiple applicable alternatives, drop those
that use default arguments. This is done indirectly by
checking applicability based on arity.
TODO: this `namesMatch` business is not spec'ed, and is
the wrong fix for SI-4592. We should instead clarify what
the spec means by "typing each argument with an undefined expected type".
What does typing a named argument entail when we don't know what
the valid parameter names are? (Since we're doing overload resolution,
there are multiple alternatives that can define different names.)
Luckily, the next step checks applicability to the individual alternatives,
so it knows whether an assignment is:
- a valid named argument
- a well-typed assignment (which doesn't necessarily have type `Unit`!)
- an error (e.g., rhs does not refer to a variable)
I propose the following solution (as a TODO):
check whether a named argument (when typing it in `doTypedApply`)
could be interpreted as an assign; `infer.checkNames` should use
the type of the well-typed assignment instead of `Unit`.
Lukas's analysis:
990fa04 misunderstood the spec of overloading resolution with
defaults. it should not discard applicable alternatives that define
defaults, but only those that use defaults in the given invocation.
bugs were shadowed because the refactoring used `alt.hasDefault` to
check whether the alternative has some parameters with defaults, but
this never worked.
d5bb19f fixed that part by checking the flags of parameters, which
fixed some but but un-shadowed others:
```
object t { def f(x: String = "") = 1; def f(x: Object) = 2 }
scala> t.f("") // should return 1, but returns 2 after d5bb19f
```
The commit message of d5bb19f also mentions that its test "should
fail to compile according to SI-4728", which is another
misunderstanding.
```
class A; class B extends A
object t { def f(x: A = null) = 1; def f(x: B*) = 2 }
t.f()
```
This should return `2`: both alternatives are applicable, so the one
that uses a default is eliminated, and we're left with the vararg one.
SI-4728 is different in that it uses explicit parameters,
`t.f(new B)` is ambiguous.
|
| |\ \
| | |
| | | |
SI-3235 math.round() returns wrong results for Int and Long
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Minimal fix for SI-3235.
This minimal fix includes deprecation messages to aid detection of probable errors.
Test verifies behavior: the correct values are returned, and deprecation messages are emitted.
|
| |\ \ \
| | | |
| | | | |
SI-8240 Consider rolling back optimizations for List
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some compiler-specific optimizations turn out to be very helpful for Lists in general.
* List map can be a lot faster (up to 5x!)
* List collect can be considerably faster (up to 3x)
* List flatMap can be a bit faster (2x)
* List take can be slightly faster (1.1x) and have better structural sharing
These appear to be unqualified wins (tested), even in a scenario with mixed collections. This is expected: detecting the builder is faster than the otherwise mandatory object creation, and multiple dispatch is mostly a wash since it was already multiple dispatch in getting to the builder.
With -optimize, map is not always such a big win, but is never slower.
Also added @noinline to map to work around an optimizer bug (SI-8334) and added a test to check that the pattern that triggers the optimizer bug does not affect any of the map-like methods.
|
| |\ \ \
| |/ /
|/| | |
SI-8251 deprecate `ListBuffer::readOnly`
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first step towards fixing the unexpected behavior of `ListBuffer`.
Many of `ListBuffer`'s operations are forwarded to the underlying `List`,
essentially leaking that abstraction to clients that call e.g., `toIterable`.
When the buffer changes, the `Iterable` obtained through `toIterable` will
reflect that change.
To avoid this exposure, call `toList` to obtain an immutable copy.
See also:
https://groups.google.com/d/msg/scala-internals/g_-gIWgB8Os/kWazrALbLKEJ
https://gist.github.com/paulp/9081797
|
| |\ \
| |/
|/| |
SI-6455 no longer rewrite .withFilter to .filter
|
| | |
| |
| |
| |
| | |
This has been deprecated for two major releases now,
but `filter`'s still preferred over `withFilter` in the wild.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The SI-8233 / 9506d52 missed one case when we need to DROP a null from
a stack: when unboxed Unit is an expected type. If we forgot to do that
in a context where two branches were involved we could end up with
unbalanced stack sizes.
Let's fix that omission and a test covering that specific case to the
original test for SI-8233.
Fixes SI-8330.
|
| |\ \
| | |
| | | |
SI-8324 fix permutation in test filename
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
SI-1503 don't assume unsound type for ident/literal patterns
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The fix only kicks in under -Xfuture. We also warn under -Xlint.
What type should a variable bound to the value matched by a pattern have?
To avoid CCEs, it should be a type that's implied by the matching
semantics of the pattern.
Usually, the type implied by a pattern matching a certain value
is the pattern's type, because pattern matching implies instance-of checks.
However, Stable Identifier and Literal patterns are matched using `==`,
which does not imply a type for the binder that binds the matched value.
The change in type checking due to this fix is that programs that used to crash with a CCE
(because we blindly cast to the type of the pattern, which a `==` check does not imply)
now get a weaker type instead (and no cast). They may still type check, or they may not.
To compensate for this fix, change `case x@Foo => x` to `case x: Foo.type => x`,
if it's important that `x` have type `Foo.type`.
See also:
- SI-4577: matching of singleton type patterns uses `eq`,
not `==` (so that the types are not a lie).
- SI-5024: patmat strips unused bindings, but affects semantics
|
| |\ \ \ \
| |_|/ /
|/| | | |
SI-8321 bundles can't be whitebox
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Given the recent glaring oversight in macro bundles, I have to have more
tests in order to make sure that things are going to work as they should.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
At the moment, bundle selection mechanism is pretty picky. If a candidate
bundle's parameter isn't either blackbox.Context, whitebox.Context or
PrefixType refinement thereof, then it's not a bundle and the user
will get a generic error.
However we can be a bit more helpful and admit classes that are almost
like bundles (looksLikeMacroBundleType), have them fail isMacroBundleType,
and then emit a much prettier error message to the user that would tell them
that bundles must be monomorphic and their sole parameter should not just
be any subtype of blackbox.Context or whitebox.Context.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's not like they were inducing bugs, but I can't see how polymorphism
can be useful for macro bundles, hence imho it's better to reduce the
number of degrees of freedom of the system.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Vanilla macros only allow blackbox.Context, whitebox.Context and
PrefixType refinements thereof. Bundles should behave in the same way.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
whitebox.Context <: blackbox.Context, so in order to check for blackboxity
it's not enough to check whether the context used is <: blackbox.Context.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8324 Fix regression in override checks for sealed classes
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
adeffda25 changed `Symbol#isEffectivelyFinal` to help the optimizer
by inferring finality within sealed class hierarchies.
However, this change wasn't neccesarily welcome for other clients of
that method. In the enclosed test case, we see that overriding checks
in `RefChecks` regressed.
This commit moves the enhanced version into a new method and
selectively uses it in the optimizer (and the tail call optimizer).
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8197 Only consider immediate params for defaults, overloading
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A recent commit fixed the behaviour of overloading with regards
to discarding candiates that include default arguments. The old
check was checking the wrong flag.
But, the new code is actually checking all parameter lists for
defaults, which led to a regression in scala-io, which is distilled
in the enclosed test case. Applications are typechecked one
parameter list at a time, so a holistic check for defaults doesn't
seem to make sense; only defaults in the first parameter list
ought to count.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-5479 deprecate DelayedInit outside of App
|
| | | | | | |
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
DelayedInit's semantics are way too surprising.
For example, it delays initialization of fields,
so that fields on objects that extend `App`
(which `extends DelayedInit`) are not initialized
until the `main` method is called.
For more details and a proposed alternative,
see https://issues.scala-lang.org/browse/SI-4330?jql=labels%20%3D%20delayedinit%20AND%20resolution%20%3D%20unresolved.
Support for `App` will continue -- we'll special case it.
|
| |\ \ \ \
| |_|/ /
|/| | | |
SI-8315 Fix crash in dead code elimination
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
It was a cache invalidation bug.
We need to mark the Code as touched to invalidate the caches
behind `predecessors` and `successors`.
|
| |\ \ \
| | | |
| | | | |
SI-8197 Overload resolution should not consider default arguments
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The spec says
> Let B be the set of alternatives in A that are applicable (§6.6)
> [...] It is an error if none of the members in B is applicable. If
> there is one single applicable alternative, that alternative is
> chosen. Otherwise, let C be the set of applicable alternatives which
> don’t employ any default argument in the application to e1, ..., em.
> It is again an error if C is empty. Otherwise, one chooses the most
> specific alternative among the alternatives in C [...].
There are many ways to interpret this, but none of them involves
excluding default getters, which is what the old code was doing.
We now exclude all alternatives that define any default arguments.
NOTE: according to SI-4728, this should fail to compile with an
ambiguity error. The compiler has been accepting this program
for all of 2.10.x, as far as I can tell, so let's not change that
for 2.11.0-RC1...
|
| |\ \ \
| | | |
| | | | |
SI-8224 Fix regression in f-bound aware LUBs
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Disable the heuristic approach to recursive bounds unless
the compiler is running under `-Xstrict-inference`.
[the above was not authored by the original author]
In db46c71e88, steps were taken to avoid blowing up in the
pathological LUB calculation needed for:
def trav = List(List(), Stream())
This skipped a level in the base class sequence when f-bounds
were detected at the current level.
In that example, when `lublist` was about to:
mergePrefixAndArgs(
typeOf[LinearSeqOptimized[A, List[A]]],
typeOf[LinearSeqOptimized[A, Stream[A]]],
)
If it proceeded (as in 2.10.3), the LUB is invalid:
error: type arguments [B[_ >: D with C <: B[_ >: D with C <: A]],s.c.immutable.LinearSeq[B[_ >: D with C <: A]] with s.c.AbstractSeq[B[_ >: D with C <: A]] with s.c.LinearSeqOptimized[B[_ >: D with C <: A],s.c.immutable.LinearSeq[A] with s.c.AbstractSeq[A] with s.c.LinearSeqOptimized[A,Immutable with Equals with java.io.Serializable] with java.io.Serializable] with java.io.Serializable] do not conform to trait LinearSeqOptimized's type parameter bounds [+A,+Repr <: s.c.LinearSeqOptimized[A,Repr]]
To avoid this, the added code would skip to the first non-F-bounded
base type of the same arity of each element in the list. This would
get to:
LinearSeqLike[D, Stream[D]]
LinearSeqLike[C, List[C]]
which are lubbable without violating the type constraints.
I don't think this was the right remedy. For starters, as seen in
this bug report, SI-8224, if the list of types are identical we
have let a perfectly good lub slip through our fingers, and end up
calculating too general a type.
More generally, if the type arguments in f-bounded positions coincide,
we don't risk calculating a ill-bounded LUB.
Furthermore, the code was widening each of the types separately;
this isn't something we want to do within `if (isUniformFrontier)`.
AFAICT this was just wasteful and as all `ts0` start with the same
type symbol, so `typeConstructorList` should be uniform.
This commit restricts this base-class skipping to situations where
the argument inferred for an type argument that is used as an f-bound
is not:
a) an existential (as created by `mergePrefixAndArgs` in invariant
positions.), or
b) equivalent to one of the corresponding input type arguments
(this is the case that fixes the regression in pos/8224.scala)
|
| |\ \ \
| | | |
| | | | |
CodePrinter added to Printers 2.11.0
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
TypedTreesPrinter added
changes based on pull request comments:
print root packages flag; tests for syntactics; SyntacticEmptyTypeTree added to Printers
|
| |\ \ \ \
| | | | |
| | | | | |
Small Predef cleanup
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Rename `conforms` to `$conforms` and put in a minimal backstop: pos/t7788.scala
TODO: predicate the backwards compatibility shim for `Predef_conforms`
on `-Xsource:2.10`
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To support the established pattern for disabling it for
an compilation unit.
Update scaladoc's knowledge of our "typeclasses".
Leave a `private[scala]` version of `StringAdd` (public in bytecode)
to ensure binary compatibility with 2.11.0-M8 for partest.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-4577 singleton type pattern test should use `eq`, not `==`
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
I find it hard to imagine anyone is relying on `case x: foo.type =>`
erroneously being compiled to `foo == x` instead of the spec'ed `foo eq x`,
so let's finally fix this.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-6675 deprecation warning for auto-tupling in patterns
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | | |
NOTE: when the deprecation warning becomes an error,
SI-6111 must become a `won't fix`
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8316 SI-8318 SI-8248 reintroduces resetAllAttrs
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Unfortunately, due to the aforementioned bugs we have to delay our triumph
over resetAllAttrs.
Therefore, I'm rolling back the internal changes to scalac introduced in
https://github.com/scala/scala/pull/3485. Our public reflection API interface
in Scala 2.11 is still going to contain only resetLocalAttrs, but both
the reifier and the label typechecker are too heavily addicted to resetAllAttrs
to do away with it right now.
|
