| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
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.
|
|\ \ \
| | | |
| | | | |
Only look for unapplies in term trees
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since Scala 2.10.2, the enclosed test case has crashed
in the backend. Before, we correctly rejected this pattern match.
My bisection landed at a merge commit f16f4ab157, although both
parents were good. So I don't quite trust that.
I do think the regression stems from the changes to allow:
case rx"AB(.+)" =>
Examples of this are in run/t7715.scala.
This commit limits the search for extractors to cases where the
function within the Apply is a term tree.
|
|\ \ \
| | | |
| | | | |
SI-7848 Xlint no warn on $sym with params
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This idea brought to you by retronym.
Also improve implicitNotFound detection at typer;
and avoid checking the standard interpolation
expression for cases like s"some $$x".
Some minor refactorings of implicitNotFound strings.
The intersobralator allows extra spaces, i.e., trims.
|
|\ \ \ \
| | | | |
| | | | | |
SI-3971 error message carat mispoints at curried methods.
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Point at the beginning of the first argument list when
reporting an error, as this is most easily associated with
the application taking place (which may involve multiple
applies in succession.)
Thanks to retronym for figuring out why issuing a better
error message broke the compiler on non-erroneous compile runs.
The changes to "treesInResult" are the consequence.
|
|/ / /
| | |
| | |
| | |
| | | |
An error suppresses all further warnings at the same position,
but multiple warnings can be heard.
|
|\ \ \
| |_|/
|/| | |
SI-7870 Detect default getter clashes in constructors
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Default getters for constructors live in the companion module.
These eluded the check for clashes in default getter names due
to overloading, which aims to give a more user friendly error
than "double definition: meth$default$1".
This commit checks for default getters in the companion module,
in addition to those in the template itself.
|
| |/
|/|
| |
| |
| | |
This reverts commit 884e1ce762d98b29594146d37b85384581d9ba96, reversing
changes made to f6fcc4431f272c707d49de68add532c452dd4b0f.
|
|\ \
| | |
| | | |
SI-7848 Xlint says what looks interpolated
|
| | |
| | |
| | |
| | | |
This idea brought to you by retronym.
|
| | |
| | |
| | |
| | | |
Avoid extra work, extra warnings.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The motivating use case was an Expecty debug string
getting flagged for `$eq`.
The test case demonstrates a different bug, in which
the position of the literal tree is changed when typer
gets rid of the unused local, so that when the tree is
re-typed in erasure, a second, spurious warning is
emitted at the start of the method. Specifically, the
second warning is not suppressed because of the
different position.
|
|\ \ \
| |_|/
|/| | |
Quasiquotes: add syntactic extractor for assignment-like trees
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are three kinds of assign-like trees:
1. Assign(lhs, rhs) // $lhs = $rhs
3. AssignOrNamedArg(lhs, rhs) // $lhs = $rhs
2. Apply(Select(f, nme.update), args :+ rhs) // $f(..$args) = $rhs
New syntactic combinator unifies all of them and lets users not to think
about these implementations details.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The parser hole I found while working on the generated positions
serves as the umbrella for a host of improvements. Upgraded
positions assigned during some specific challenging situations mostly
involving the creation of synthetic trees, e.g. for comprehensions
and closures. While doing so improved some error messages.
Eliminated some of the most glaring duplication in the parser.
It's written like there is some payoff associated with being
spectacularly imperative. Not so far.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Can't ensure range position points are meaningful when we never
see them. To limit noise, only print the point when it != start.
[x:y] // point=x, start=x, end=y
[p/x:y] // point=p, start=x, end=y
I'm open to a different syntax.
Also prints NoPosition as [X] rather than [NoPosition] because
noise is for construction workers and attenders of rock concerts.
Some range position and parser tests are included so we can see
the checkfile change when the forthcoming fix happens (either an
error message improvement or a positional one.)
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One last flurry with the broom before I leave you slobs to code
in your own filth. Eliminated all the trailing whitespace I
could manage, with special prejudice reserved for the test cases
which depended on the preservation of trailing whitespace.
Was reminded I cannot figure out how to eliminate the trailing
space on the "scala> " prompt in repl transcripts. At least
reduced the number of such empty prompts by trimming transcript
code on the way in.
Routed ConsoleReporter's "printMessage" through a trailing
whitespace stripping method which might help futureproof
against the future of whitespace diseases. Deleted the up-to-40
lines of trailing whitespace found in various library files.
It seems like only yesterday we performed whitespace surgery
on the whole repo. Clearly it doesn't stick very well. I suggest
it would work better to enforce a few requirements on the way in.
|
|\
| |
| | |
SI-1909 SI-3832 SI-7007 SI-7223 Improved handling of larval objects
|
| |
| |
| |
| |
| |
| |
| | |
Rather than the old behaviour, which compiled successfully
but led us into the jaws of a LinkageError.
Related to SI-6666.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
SI-1909 modified LambdaLift to lift in auxiliary constructors methods as STATIC
so they could be called before the self-constructor was called.
That allowed for:
class Foo (x: Int) {
def this() = this( {
def bar() = 5
bar
})
}
However, if the method is in a statement that trails the self constructor call,
this is unnecessary and in fact incorrect as it robs the lifted method of `this`.
This commit uses the machinery established in SI-6666 to limit the STATIC-ness
of lifted methods to those used in arguments for self-constructor calls.
This is used exclusively; the `isAuxillaryConstructor` check wasn't the right
way to solve this, as was seen by the regression it caused in SI-3832.
A new test case shows that we can statically lift methods in super-constructor
calls, rather than just self-constructor calls.
We also have to avoid statically lifting objects in these positions. For now,
I just emit a dev warning that a VerifyError is in your future. With some more
thought we could escalate that to a implementation restriction and emit an error.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TreeDSL has no future - it was always a temporary measure
waiting for something like quasiquotes to come along. In this
commit I cull as much of it as I can, especially the delicate
matter of creating new DefDefs and ValDefs, which I completely
turn over to the old style creators.
I unified all the symbol-based DefDef and ValDef creators under
a single method, since it was yet another place where ctrl-C and
ctrl-V were being punched with glee. Was beaten to the punch on
adding copyTypeDef to fill out the *Def creators.
Eliminated as many redundant positioning calls as I could find.
If you are creating a DefTree tree based on a symbol, it will
always have an atPos(sym.pos) { ... } wrapped around it. You
don't need another one.
All of this is motivated by positions work: positions are
assigned in so many places and in such an ad hoc fashion that
it is impossible to bring consistency to that without first
bringing some consistency to tree creation.
|
|\ \
| | |
| | | |
SI-7622 Clean Up Phase Assembly
|
| | |
| | |
| | |
| | | |
Restores the verbiage "run right after".
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Let optimiser components and continuations plugin opt-out
when required flags are not set.
Wasted time on a whitespace error in check file, so let
--debug dump the processed check file and its diff.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Plugins can interrogate options and declare themselves not
enabled. The plugin itself can return false from its init
if the options do not compute. A plugin phase component
can declare itself not enabled, same as an internal phase.
No one exploits this facility at this commit.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Refactor the calculation of the "phase chain" a bit.
In particular, initial and terminal phases are not special
except that they must be head and last.
When done, filter for enabled phases. At this commit,
nobody claims to be disabled.
Additional sanity support of phases settings.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixing hash on nodes makes fault detection deterministic,
which aids testing.
Error messages are shortened and .dot files are dumped
automatically on faults to guard against future flakiness.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Foo.this.x and Foo.super.x were roughly unrelated in the eyes
of isSubType. I implemented conformance as described in the comment:
This is looking for situations such as B.this.x.type <:< B.super.x.type.
If it's a ThisType on the lhs and a SuperType on the right, and they originate
in the same class, and the 'x' in the ThisType has in its override chain
the 'x' in the SuperType, then the types conform.
I think this is overly conservative but it's way ahead of
where it was.
|