| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
SI-7605 Deprecate procedure syntax
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit covers three cases:
- constructor definitions (def this {...})
- concrete method definitions (def foo {...})
- abstract method declarations (def foo)
The deprecation is currently hidden behind -Xfuture pending IDE support
for migrating users from procedures to methods.
|
|\ \
| | |
| | | |
SI-6385 Avoid bridges to identical signatures over value classes
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As Paul noted in the comments to SI-6260 (from which I mined some
test cases) "there is no possible basis for conflict here":
scala> class C[A](val a: Any) extends AnyVal
defined class C
scala> class B { def x[A](ca: C[A]) = () }
defined class B
scala> class D extends B { override def x[A](ca: C[A]) = () }
<console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D
which overrides method x: [A](ca: C[A])Unit in class B
clashes with definition of the member itself;
both have erased type (ca: Object)Unit
class D extends B { override def x[A](ca: C[A]) = () }
^
What was happening?
Bridge computation compares `B#x` and `D#x` exitingErasure, which
results in comparing:
ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)])
These types were considered distinct (on the grounds of the unique
type hash consing), even though they have the same erasure and
involve the same value class.
That triggered creation of an bridge. After post-erasure eliminates
the `ErasedValuedType`s, we find that this marvel of enginineering is
bridges `(Object)Unit` right back onto itself. The previous
resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed
that we detected the zero-length bridge and reported it nicely, which
happened after related work in SI-6260. But we can simply avoid
creating in it in the first place.
That's what this commit does. It does so by reducing the amount
of information carried in `ErasedValueType` to the bare minimum needed
during the erasure -> posterasure transition.
We need to know:
1. which value class wraps the value, so we can box and unbox
as needed
2. the erasure of the underlying value, which will replace this
type in post-erasure.
This construction means that the bridge above computation now
compares:
ErasedValueType(C, Any) =:= ErasedValueType(C, Any])
I have included a test to show that:
- we don't incur any linkage or other runtime errors in the
reported case (run/t6385.scala)
- a similar case compiles when the signatures align
(pos/t6260a.scala), but does *not* compile when the just
erasures align (neg/t6260c.scala)
- polymorphic value classes continue to erase to the instantiated
type of the unbox: (run/t6260b.scala)
- other cases in SI-6260 remains unsolved and indeed unsolvable
without an overhaul of value classes: (neg/t6260b.scala)
In my travels I spotted a bug in corner case of null, asInstanceOf
and value classes, which I have described in a pending test.
|
|/ /
| |
| |
| | |
(for f in $(find test -name '*.check' -o -name '*.flags'); do bare=$(echo $f | sed -E 's/\.\w+$//'); ([[ -f "$bare" ]] || [[ -d "$bare" ]] || [[ -f "$bare.scala" ]] || [[ -f "$bare.test" ]] || echo $f) done;) | xargs rm
|
| |
| |
| |
| | |
Patern translation now happens earlier.
|
|\ \
| |/
|/| |
Tests for protected access
|
| |
| |
| |
| |
| | |
I've marked a few minor cases in the test with !!! where I believe
the behaviour goes beyond the spec.
|
| |
| |
| |
| | |
c39f26382dddaa7 fixed the bug but didn't commit a test case.
|
|\ \
| | |
| | | |
better macro impl shape errors
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With the advent of quasiquotes, we allowed both arguments and return types
of macro impls to be c.Tree's (as opposed to traditional c.Expr[T]'s).
This warrants an update of macro def <-> macro impl signature mismatch
errors that include a printout of suggested macro impl signatures. Now
along with a signature that contains exprs, we suggest another signature
that has all exprs replaced by trees
|
|\ \ \
| | | |
| | | | |
Deterministic warnings for pattern matcher, take 2
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The previous swing at determinism, ebb01e05cbe4, made decent
contact but apparently didn't hit it out of the park. The test
wavered every hundred or so runs, as witnessed occasionally in
nightly builds or pull request validation.
I setup a test to run neg/7020.scala a few hundred times, and
could trigger the failure reliably.
I then swept through the pattern matcher in search of HashMap and
HashSet creation, and changed them all to the Linked variety.
The results of that are published in retronym#ticket/7020-3 [1].
This commit represents the careful whittling down of that patch
to the minimal change required to exhibit determinism.
[1] https://github.com/retronym/scala/compare/ticket/7020-3
|
|\ \ \
| | | |
| | | | |
SI-7519: Additional test case covering sbt/sbt#914
|
| |/ / |
|
|\ \ \
| |/ /
|/| | |
deprecates raw tree manipulation facilities in macros.Context
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add support for packages into quasiquotes and toolbox, improve handling of fresh names, unhardcode quasiquote expansion logic
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In order to implement this a new parser entry point
`parseStatsOrPackages` that augments current parseStats with ability
to parse "package name { ... }" syntax.
|
|\ \ \ \
| |_|/ /
|/| | | |
Merge 2.10.x to master (again)
|
| |\ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These are still impudently being non-deterministic.
I've reopened the ticket so we can take another swing at it.
A well targetted s/HashMap/LinkedHashMap/ will almost certainly
be the salve.
fail - neg/t7020.scala [output differs]% scalac t7020.scala
t7020.scala:3: warning: match may not be exhaustive.
It would fail on the following inputs: List((x: Int forSome x not in (1, 2, 4, 5, 6, 7))), List((x: Int forSome x not in (1, 2, 4, 5, 6, 7)), _), List(1, _), List(2, _), List(4, _), List(5, _), List(6, _), List(7, _), List(??, _), List(_, _)
List(5) match {
^
t7020.scala:10: warning: match may not be exhaustive.
It would fail on the following inputs: List((x: Int forSome x not in (1, 2, 4, 5, 6, 7))), List((x: Int forSome x not in (1, 2, 4, 5, 6, 7)), _), List(1, _), List(2, _), List(4, _), List(5, _), List(6, _), List(7, _), List(??, _), List(_, _)
List(5) match {
^
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
SI-3346 implicit parameters can now guide implicit view inference
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This simple patch makes it possible for implicit views to benefit from
fundep-guided type inference, eliminating a nasty special case in
implicit inference.
Here are the changes that I had to apply to the tests (they exposed
quite a number of interesting questions that I was happy to answer):
1) neg/t5845.scala now works, so I moved it to pos. That easily makes sense,
because the test was just a canary to track previous state of things.
2) neg/divergent_implicit.scala, neg/t5578.scala and neg/t7519.scala
changed their messages to less informative ones, because inapplicable
implicit views now get disqualified early and therefore don't display
their error messages to the user. This is an unfortunate but necessary
byproduct of this change, and one can argue that the behavior is now
completely consistent with implicit vals (that also don't explain why
this or that implicit val got disqualified, but rather display a generic
implicit value not found message).
3) scaladoc/implicits-chaining.scala and scaladoc/implicits-base.scala.
Immediate culling of apriori inapplicable implicit views messes things up
for Scaladoc, because it's interested in potentially applicable views,
having infrastructure to track various constraints (type bounds, requirements
for implicit parameters, etc) that guide applicability of views and then
present it to the user. Therefore, when scaladoc is detected, implicit search
reverts to the old behavior.
4) We still cannot have Jason's workaround to type constructor inference
mentioned in comments to SI-3346, because it's not really about implicit
parameters of implicit views, but about type inference flowing from the
implicit parameter list to a preceding parameter list in order to affect
inference of an implicit view. This is something that's still too ambitious.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Merge 2.10.x into master
|
| |\ \ \ \ \
| | | |/ / /
| | |/| | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
build.number
test/files/neg/classmanifests_new_deprecations.check
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Deprecation checks in RefChecks were looking into all TypeTrees
to find references to deprecated type aliases. However, when the
compiler infers a type argument or type of a member it creates
a TypeTree (with a null original) that was also leading to warnings.
I ran into this problem often when upgrading a build from SBT 0.12
to 0.13: a plugin I was using used the deprecated type alias, and I
suffered transitively when I used methods from its API.
This commit disables the checks for inferred TypeTree-s.
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Only one seems to indicate something new:
((x: Int) => 0): NonClassType
I believe that we shouldn't pursue SAM translation for that case,
and fallthrough to Function1. That would allow for an implicit view
to finish the job.
|
|\ \ \ \ \
| | |_|/ /
| |/| | |
| | | | |
| | | | | |
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
| |\ \ \ \
| | | | | |
| | | | | | |
SI-7239 A bonus test case from [scala-user]
|
| | | |_|/
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Thanks to Ilya Denisov for another sample [1] that progressed
with the fix for SI-7239, 174334b.
[1] https://groups.google.com/forum/#!topic/scala-user/8rZeCeiTYDo
|
| |\ \ \ \
| | | | | |
| | | | | | |
SI-7895 Error reporting: avoid cascading, truncation
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`missing1.foo(missing2)` now reports `missing1` and `missing2` as
not found. Previously, only the first was reported.
The arguments are typed with an expected type ErrorType. We propagate
this through as the inferred type of anonymous function parameters
to avoid issuing cascading "missing parameter type" errors in code
like:
scala> Nil.mapp(x => abracadabra)
<console>:8: error: value mapp is not a member of object Nil
Nil.mapp(x => abracadabra)
^
<console>:8: error: not found: value abracadabra
Nil.mapp(x => abracadabra)
^
This was in response to unwanted changes in the output of existing
neg tests; no new test is added.
Similarly, we refine the errors in neg/t6436b.scala by to avoid
cascaded errors after:
type mismatch; found: StringContext, required: ?{def q: ?}
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Rather than just the first.
For example, `foo(wizzle, wuzzle, woggle)` should report all three
not-found symbols.
|
| | | |_|/
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | | |
If we can't type check the `Foo` in `case Foo(a, b) => (a, b)`,
we should enter error symbols for `a` and `b` to avoid further
errors being reported in the case body.
|
| |\ \ \ \
| | |_|/ /
| |/| | | |
Generalize OverridingPairs to SymbolPairs.
|
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Increases your chance of knowing what is going on in
OverridingPairs. Introduces some new abstractions which I
hope for your own sakes you will put to use in some way:
RelativeTo: operations relative to a prefix
SymbolPair: two symbols being compared for something, and
the enclosing class where the comparison is being performed
Fixed a minor bug with access by accident by way of more
principled pair analysis. See run/private-override.scala.
Upgraded the error message issued on certain conflicts
to give the line numbers of both conflicting methods, as
opposed to just one and you go hunting.
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Given:
def id[A](a: A): A = a
def foo(f: (=> Int) => Int) = ()
foo(id)
We eta-expanded `id` and inferred `A` to be `=> Int` to satisfy the
expected type set forth by the formal parameter `f`.
We really shouldn't go about inferring types that we can't *write*.
Our attempt to do so led promptly into a `ClassCastException` in the
enclosed test.
This commit:
- drops by-name-ness during `inferExprInstance`
- tests that this results in a type error for the reported bug
(neg/t7899)
- tests that a method with a by-name parameter can still be
eta expanded to match function with a corresponding by-name
parameter (run/t7899)
- discovers the same latent CCE in pos/t7584
- now that would be a type error
- so we compensate by using placeholder functions rather than
eta-expansion.
- and move that that test to `run` for good measure.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this change:
scala> trait T { def apply(a: Int): Int }
defined trait T
scala> ((x: Int, y: Int) => 0): T
<console>:9: error: object creation impossible, since method apply in trait T of type (a: Int)Int is not defined
((x: Int, y: Int) => 0): T
^
After the change, these cases report the same errors as they do
*without* -Xexperimental.
|
|\ \
| | |
| | | |
SI-7886 unsoundness in pattern matcher.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Introduces -Xstrict-inference to deal with the significant
gap between soundness and what presently compiles. I'm hopeful
that it's TOO strict, because it finds e.g. 75 errors compiling
immutable/IntMap.scala, but it might be that bad.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I tracked down what was behind the issue described here:
// TODO: fix the illegal type bound in pos/t602 -- type inference
// messes up before we get here:
/*override def equals(x$1: Any): Boolean = ...
// Span[Any] --> Any is not a legal type argument for Span!
val o5: Option[com.mosol.sl.Span[Any]] =
*/
...which led straight to the unsoundness seen in neg/t7886.
It is dangerous to have an expected type of "Any" because
the type system will blithely ignore kind errors, since "Any"
can absorb anything. The consequence in this instance was
that inferring the case constructor for a type like
Foo[T <: Bound]
if done with expected type Any, this would come up with Foo[Any].
I altered it to use expected type Foo[T], which lets the dummy
type parameter survive to carry the bound forward and restores
sense to the inference. The before/after output for -Xprint:patmat
on pos/t602.scala is:
15c15
< if (x1.isInstanceOf[com.mosol.sl.Span[Any]])
---
> if (x1.isInstanceOf[com.mosol.sl.Span[K]])
17c17
< <synthetic> val x2: com.mosol.sl.Span[Any] = \
(x1.asInstanceOf[com.mosol.sl.Span[Any]]: com.mosol.sl.Span[Any]);
---
> <synthetic> val x2: com.mosol.sl.Span[K] = \
(x1.asInstanceOf[com.mosol.sl.Span[K]]: com.mosol.sl.Span[K]);
19,20c19,20
< val low$0: Option[Any] = x2.low;
< val high$0: Option[Any] = x2.high;
---
> val low$0: Option[K] = x2.low;
> val high$0: Option[K] = x2.high;
A file in the library depended (needlessly) on the unsoundness.
It was easy to fix but reminds us this may affect existing code.
|
|\ \ \
| | | |
| | | | |
SI-7859 Value classes may wrap a non-public member
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We allow value class constructors to be non-public, so to be regular,
we should also allow the same for the param accessor.
This commit uses the 'makeNotPrivate' machinery to ensure that
the backend can generate the requisite unboxing calls.
This commit:
- refactors the code that enforced the restrictions, improving
a few error messages and positions. The remaining restrictions
needed some rewording in light of this change.
- allows value classes to have non-public, val parameters.
private[this] / protected[this] are still disallowed as value
classes don't have a concept of `this`, and because trying to
accomdate then would complicate the implementation.
This means that `class C(x: Int) extends AnyVal` is not allowed,
the user still must write `private val x: Int` or `val x: Int`.
- Outlaw `class C()()(val x: Int) extends AnyVal` to curtail any
bugs that might lurk in such a formulation.
The tests:
- Show that the privacy is respected in the typer phase, under
joint and separate compilation. We don't want a repeat performance
of SI-6601.
- Show that code that needs compiler-generated unboxes works under
both compilation scenarios
- Checks that the remaining restrictions are enforced and well
communicated.
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously it was enough to just extend scala.reflect.macros.Macro, which
created some loopholes, but now scalac enforces that bundles:
1) Are static (not necessarily top-level, but just static)
2) Are traits (objects shouldn't be bundles anyway, and classes bring
complications with their ctors which require special treatment in
generated classes, so why support them if they don't bring anything
new to the table?)
3) Are monomorphic (again, this brings unnecessary complications wrt
auxiliary code generation, so I don't see merit in supporting
polymorphic bundles, whatever that a polymorphic bundle could mean)
4) Don't provide concrete implementation for Macro.c (if they do then
what is the point?)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I had covered a few more cases working on this recently.
The warnings in several more cases involving polymorphism,
currying, and selects vs. idents receive more refined
handling.
|
|\ \ \
| | | |
| | | | |
SI-7629 Deprecate view bounds
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This introduces a warning(/error with -Xfuture) with a general
migration advice. The IDE can use the warning to offer a quick fix
with the specific refactoring necessary.
|