| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The transformer in the superaccessors phase uses the var
`validCurrentOwner` to track whether we're in a part of the
code that won't end up in the host method, and as such, will
need to access super-method via a super-accessor.
But, this bit of bookkeeping was not correctly reset after traversing
out of a local class. A `VerifyError` ensued.
This commit changes `atOwner` to save and restore that flag, rather
than leaving it set to `true`.
I've also added a test variation using a by-name argument.
|
|\
| |
| | |
SI-8395 Regression in pattern matching with nested binds
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Regressed in https://github.com/scala/scala/pull/2848. In particular,
see 0cf47bdb5b and 017460e63c.
Because of the regression, this pattern:
(s @ (_s @ (_: String)))
was translated into `typeTestStep`, rather than a `bindingStep`. This
came down the the use of `unbind` in the `TypeBound` extractor.
My first step was to remove the `unbind`. That led to another
problem: the tree now matches `SymbolAndTypeBound`, which extracted
`symbol = s, tpe = String`, ignoring the `_s`. I changed that
extractor to no longer recursively apply to the sub-pattern tree,
which is what `MaybeTypedBound` used to do.
I also checked for other uses of `unbind` in the match translation.
The only place I found it is in `BoundTree#pt`. I believe that this
usage is correct, or at least, not obviously incorrect.
|
|\ \
| |/
|/| |
SI-8376 Fix overload resolution with Java varargs
|
| |
| |
| |
| |
| | |
`T*` rather than `<repeated>[T]`, as we alreday do for Scala repeated
parameters.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When comparing specificity of two vararg `MethodTypes`, `isAsSpecific`
gets to:
```
case mt @ MethodType(_, _) if bothAreVarargs =>
checkIsApplicable(mt.paramTypes mapConserve repeatedToSingle)
```
The formal parameter type of a Java varargs parameter is represented
as `tq"${defintions.JavaRepeatedParamClass}[$elemTp]"`. For a Scala
repeated parameter, we instead use `defintions.RepeatedParamClass`.
`bothAreVarargs` detects `JavaRepeatedParamClass`, by virtue of:
```
def isRepeatedParamType(tp: Type) = isScalaRepeatedParamType(tp) || isJavaRepeatedParamType(tp)
```
But, `repeatedToSingle` only considers `RepeatedParamClass`.
This bug was ostensibly masked in 2.10.3, but became apparent after
a not-quite-refactoring in 0fe56b9770. It would be good to pin that
change down to a particular line, but I haven't managed that yet.
|
|\ \
| | |
| | | |
SI-8363 Disable -Ydelambdafy:method in constructor position
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As @magarciaEPFL has done in his experimental optimizer [1], we can
avoid running into limitations of lambdalift (either `VerifyError`s,
ala SI-6666, or compiler crashes, such as this bug), by using the
old style of "inline" lambda translation when in a super- or self-
construtor call.
We might be able to get these working later on, but for now we
shouldn't block adoption of `-Ydelamndafy:method` for this corner
case.
[1] https://github.com/magarciaEPFL/scala/blob/GenRefactored99sZ/src/compiler/scala/tools/nsc/transform/UnCurry.scala#L227
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously one could match a partial function with match quasiquote:
scala> val q"$scrutinee match { case ..$cases }" = q"{ case Foo => Bar
}"
scrutinee: universe.Tree = <empty>
cases: List[universe.CaseDef] = List(case Foo => Bar)
This was quite annoying as it leaked encoding of partial functions as
Match trees with empty tree in place of scrutinee.
This commit make sure that matches and partial functions are disjoint
and don't match one another (while preserving original encoding under
the hood out of sight of the end user.)
|
|\ \
| | |
| | | |
SI-8385 make sure $quasiquote$tuple gets reified properly
|
| | |
| | |
| | |
| | |
| | |
| | | |
Previously due to greediness of SyntacticApplied there was a chance that
quasiquote tuple placeholder got reified as its representation rather
than its meaning.
|
|\ \ \
| | | |
| | | | |
SI-8331 make sure type select & applied type doesn't match terms
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Due to tree re-use it used to be the fact that type quasiquotes could
match term trees. This commit makes sure selections and applied type and
type applied are all non-overlapping between q and tq.
|
|\ \ \
| |_|/
|/| | |
SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefined
|
| | |
| | |
| | |
| | | |
this is some weird stuff
|
|\ \ \
| | | |
| | | | |
SI-8375 saner binary incompat errors for macros
|
| | | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Inspired by Brian McKenna's RC1 migration experience, this commit improves
macro impl binding validation in order to provide more helpful diagnostic
for this quite frequent class of errors.
|
|\ \ \
| |_|/
|/| | |
SI-8364 fixes cxTree lookup for imports
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
This is reminiscent of the bug that I recently fixed in paradise:
https://github.com/scalamacros/paradise/commit/0dc4e35883d357b7cbcdfd83b5b4821c1dcc0bb1.
When doing something non-standard with contexts, we usually have to keep
in mind that new contexts are created not only for trees that demarcate
blocks of code, but also for imports.
|
|\ \
| | |
| | | |
SI-8369 resetAttrs now correctly accounts for skolems
|
| |/
| |
| |
| |
| | |
resetAttrs (née resetLocalAttrs) has been oblivious to existence of skolems.
Not anymore, which prevents us from reverting to the untyper nightmare.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The b8a76f688c6ce2a4c305da064303bb46b53be875 introduced ArrayOps.{unzip,
unzip3} methods. Both of those methods have ClassTags as context bounds on
their type parameters so they can create (and return) instances of Arrays.
The type inference for those methods is supposed to be guided by
implicit evidence that T <: (T1, T2) (or T <: (T1, T2, T3) in unzip3 case).
However, context bounds are desugared into implicit parameters that
prepended in front of implicit parameters declared in source code. That
means the implicit evidence won't have a chance to guide type inference
because it comes as last implicit parameter.
This commit desugars context bounds and puts them at the end of implicit
parameter list. This way type inference is guided properly and we get
expected compiler errors for missing class tags.
The change to parameters order breaks binary compatibility with respect
to 2.11.0-RC1. I added filters to our binary compatibility configuration
files. We can get rid of them as soon as 2.11.0 is out.
|
|/
|
|
|
| |
This commit merely documents current (suboptimal) error message printed
for the code reported in SI-8372. The next commit will fix the problem.
|
|\
| |
| | |
SI-8281 check for unbound placeholder parameters in quasiquote parser
|
| | |
|
| |
| |
| |
| |
| |
| | |
A new api that simplifies handling of implicit parameters has been
mistakingly supporting just methods parameters. This commit adds
support for class parameters too.
|
|\ \
| | |
| | | |
SI-8333 can't use modifiers if class is in a block
|
| |/
| |
| |
| |
| |
| | |
Was caused by the ordering of parser cases. Need to check for definition
first due to the fact that modifiers unquote looks like identifier from
parser point of view.
|
|\ \
| | |
| | | |
SI-8285 use correct kind of map for quasiquote positions
|
| |/
| |
| |
| |
| |
| |
| | |
Previously mutable.ListMap was used with assumption that it preserved
order of inserted elements (but it doesn't). Surprisingly logic that
assumed ordered elements worked mosly fine on unordered ones. I guess
two bugs can cancel each other out.
|
|\ \
| | |
| | | |
SI-8275 allow to directly extract block contents of the case def
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Deconstruction of blocks in case clauses uncovered asymmetry between
construction and deconstruction of blocks:
tree match { case cq"$pat => ..$cases" => cq"$pat => ..$cases" }
Such an identity-like transformation used to produce an incorrect tree due
to the fact that zero-element block was mistakingly associated with
empty tree. Such association was used as a solution to block flatenning:
val ab = q"a; b"
q"..$ab; c" // ==> q"a; b; c"
val a = q"a"
q"..$a; c" // ==> q"a; c"
val empty = q""
q"..$empty; c" // ==> q"c"
This commit changes meaning of zero-element block to a be a synthetic unit
instead. This is consistent with parsing of `{}`, cases, ifs and
non-abstract empty-bodied methods. A local tweak to block flattenning is
used to flatten empty tree as empty list instead.
|
| |/
| |
| |
| |
| | |
Due to the fact that blocks in cases are implicit one might expect to be
able to extract its contents with `..$`.
|
|/ |
|
| |
|
|\
| |
| | |
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
|
| | | |
|