| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding
Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.
For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html
Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
|
|
|
|
|
|
|
|
| |
Restores a form of the previous peekAhead bookkeeping.
Instead of tracking the current token and offset outside
of xxxAhead, peekingAhead uses `in.prev` and will push
back if the operation results in an empty tree.
|
|
|
|
| |
Check files
|
|
|
|
|
|
|
| |
Centralizes the scattered logic surrounding erroneous
pattern syntax. Consolidates the redundant lookahead
implementations. Eliminates var manipulation in favor
of recursion.
|
|
|
|
|
|
| |
The differences when running with method based delambdafication aren't
important enough yet to create specialized versions that use method
based delambdafication.
|
|
|
|
|
|
| |
This commit includes several tests where there's a variation in
signatures between inline delambdafication and method based
delambdafication.
|
|
|
|
|
|
| |
This commit adds a do-nothing phase called "Delambdafy" that will
eventually be responsible for doing the final translation of lambdas
into classes.
|
|\
| |
| | |
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.
|