| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-8841 report named arg / assignment ambiguity also in silent mode.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For local definitions (eg. in a block that is an argument of a method
call), the type completer may have a silent context. A CyclicReference
is then not thrown but transformed into a NormalTypeError. When
deciding if 'x = e' is an assignment or a named arg, we need to report
cyclic references, but not other type errors. In the above case, the
cyclic reference was not reported.
Also makes sure that warnings are printed after typing argument
expressions.
|
| |\ \
| | |
| | | |
SI-9041 Avoid unreported type error with overloading, implicits
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If `qual.foo(args)` fails to typecheck, we fall back to
`ImplicitView(qual).foo(args)`. However, if the original type error
stemmed from an overload ambiguity, the tree `Select(qual, 'foo')`
holds onto an error symbol. The fall back attempt just returns an
`Apply` tree containing the erroneous qualifier, as it does not
want to issue cascading type errors.
This commit replaces the error symbol with a `NoSymbol`, which
triggers the second try typechecking to perform overload resolution
again.
A more principled fix might be to more pervasively duplicate trees
before mutating their types and symbols, that this is beyond the
scope of this bug fix.
|
| |\ \ \
| | | |
| | | | |
SI-9093 Fix value discarding / multiple param list crasher
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The type error stemming from missing argument list was being
swallowed when the expected type was `Unit` and there were
undetermined type parameters in the expression.
This commit modifies `adapt` to avoid using
`instantiateExpectingUnit` when the tree is typed with `MethodType`.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An -Xlint:stars-align warning for the case of patterns
with at least one "fixed" component and a varargs component.
Warn if the fixed patterns don't exactly align with the fixed
value components, such that a sequence wildcard aligns exactly
with the varargs component (either a T* parameter in a case class
or a Seq[T] in an extractor result).
This addresses the case of the xml.Elem extractor, which does
not correspond to the Elem class constructor. One can be fooled
into supplying an extra field for extraction.
Vanilla extractors of type `Option[Seq[_]]` are unaffected by
this flag. It's OK to ask for `case X(a, b, c)` in the expectation
that three results are forthcoming. There is no semantic confusion
over where the varargs begin.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
| |\ \
| |/
|/| |
Avoid the `CNF budget exceeded` exception via smarter translation into CNF.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The exhaustivity checks in the pattern matcher build a propositional
formula that must be converted into conjunctive normal form (CNF) in
order to be amenable to the following DPLL decision procedure.
However, the simple conversion into CNF via negation normal form and
Shannon expansion that was used has exponential worst-case complexity
and thus even simple problems could become untractable.
A better approach is to use a transformation into an _equisatisfiable_
CNF-formula (by generating auxiliary variables) that runs with linear
complexity. The commonly known Tseitin transformation uses bi-
implication. I have choosen for an enhancement: the Plaisted
transformation which uses implication only, thus the resulting CNF
formula has (on average) only half of the clauses of a Tseitin
transformation.
The Plaisted transformation uses the polarities of sub-expressions to
figure out which part of the bi-implication can be omitted. However,
if all sub-expressions have positive polarity (e.g., after
transformation into negation normal form) then the conversion is
rather simple and the pseudo-normalization via NNF increases chances
only one side of the bi-implication is needed.
I implemented only optimizations that had a substantial
effect on formula size:
- formula simplification, extraction of multi argument operands
- if a formula is already in CNF then the Tseitin/Plaisted
transformation is omitted
- Plaisted via NNF
- omitted: (sharing of sub-formulas is also not implemented)
- omitted: (clause subsumption)
|
| |\ \
| | |
| | | |
SI-9015 Reject 0x and minor parser cleanup
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Only print error results. Show deprecated forms.
Test for rejected literals and clean up parser
There was no negative test for what constitutes a legal literal.
The ultimate goal is for the test to report all errors in
one compilation.
This commit follows up the removal of "1." syntax to simplify
number parsing. It removes previous paulp code to contain the
erstwhile complexity.
Leading zero is not immediately put to the buffer. Instead,
the empty buffer is handled on evaluation. In particular, an
empty buffer due to `0x` is a syntax error.
The message for obsolete octal syntax is nuanced and deferred
until evaluation by the parser, which is slightly simpler to
reason about.
Improve comment on usage of base
The slice-and-dicey usage of base deserves a better
comment. The difference is that `intVal` sees an empty
char buffer for input `"0"`.
|
| |\ \ \
| | | |
| | | | |
SI-9008 Fix regression with higher kinded existentials
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Allow a naked type constructor in an existential type if
we are directly within a type application.
Recently, 84d4671 changed nested context creation to avoid passing
down the `TypeConstructorAllowed`, which led to missing kind errors
in code like `type T[({type M = List})#M]`.
However, when typechecking `T forSome { quantifiers }`, we create
a nested context to represent the nested scope introduced for the
quantifiers. But we need to propagate the `TypeConstructorAllowed`
bit to the nested context to allow for higher kinded existentials.
The enclosed tests show:
- pos/t9008 well kinded application of an hk existential
- neg/t9008 hk existential forbidden outside of type application
- neg/t9008b kind error reported for hk existential
Regressed in 84d4671.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When unpickling a class, we create stub symbols for references
to classes absent from the current classpath. If these references
only appear in method signatures that aren't called, we can
proceed with compilation. This is in line with javac.
We're getting better at this, but there are still some gaps.
This bug is about the behaviour when a package is completely
missing, rather than just a single class within that package.
To make this work we have to add two special cases to the unpickler:
- When unpickling a `ThisType`, convert a `StubTermSymbol` into
a `StubTypeSymbol`. We hit this when unpickling
`ThisType(missingPackage)`.
- When unpickling a reference to `<owner>.name` where `<owner>`
is a stub symbol, don't call info on that owner, but rather
allow the enclosing code in `readSymbol` fall through to
create a stub for the member.
The test case was distilled from an a problem that a Spray user
encountered when Akka was missing from the classpath.
Two existing test cases have progressed, and the checkfiles are
accordingly updated.
|
| |\ \
| | |
| | | |
SI-8597 Improved pattern unchecked warnings
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The spec says that `case _: List[Int]` should be always issue
an unchecked warning:
> Types which are not of one of the forms described above are
> also accepted as type patterns. However, such type patterns
> will be translated to their erasure (§3.7). The Scala compiler
> will issue an “unchecked” warning for these patterns to flag
> the possible loss of type-safety.
But the implementation goes a little further to omit warnings
based on the static type of the scrutinee. As a trivial example:
def foo(s: Seq[Int]) = s match { case _: List[Int] => }
need not issue this warning.
These discriminating unchecked warnings are domain of
`CheckabilityChecker`.
Let's deconstruct the reported bug:
def nowarn[T] = (null: Any) match { case _: Some[T] => }
We used to determine that if the first case matched, the scrutinee
type would be `Some[Any]` (`Some` is covariant). If this statically
matches `Some[T]` in a pattern context, we don't need to issue an
unchecked warning. But, our blanket use of `existentialAbstraction`
in `matchesPattern` loosened the pattern type to `Some[Any]`, and
the scrutinee type was deemed compatible.
I've added a new method, `scrutConformsToPatternType` which replaces
pattern type variables by wildcards, but leaves other abstract
types intact in the pattern type. We have to use this inside
`CheckabilityChecker` only. If we were to make `matchesPattern`
stricter in the same way, tests like `pos/t2486.scala` would fail.
I have introduced a new symbol test to (try to) identify pattern
type variables introduced by `typedBind`. Its not pretty, and it
might be cleaner to reserve a new flag for these.
I've also included a test variation exercising with nested matches.
The pattern type of the inner case can't, syntactically, refer to the
pattern type variable of the enclosing case. If it could, we would
have to be more selective in our wildcarding in `ptMatchesPatternType`
by restricting ourselves to type variables associated with the closest
enclosing `CaseDef`.
As some further validation of the correctness of this patch,
four stray warnings have been teased out of
neg/unchecked-abstract.scala
I also had to changes `typeArgsInTopLevelType` to extract the type
arguments of `Array[T]` if `T` is an abstract type. This avoids the
"Checkability checker says 'Uncheckable', but uncheckable type
cannot be found" warning and consequent overly lenient analysis.
Without this change, the warning was suppressed for:
def warnArray[T] = (null: Any) match { case _: Array[T] => }
|
| |\ \ \
| | | |
| | | | |
SI-5639 Fix spurious discarding of implicit import
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To be conservative, I've predicated this fix in `-Xsource:2.12`.
This is done in separate commit to show that the previous fix
passes the test suite, rather than just tests with `-Xsource:2.12`.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Scala fa0cdc7b (just before 2.9.0), a regression in implicit
search, SI-2866, was discovered by Lift and fixed. The nature of
the regression was that an in-scope, non-implicit symbol failed to
shadow an eponymous implicit import.
The fix for this introduced `isQualifyingImplicit` which discards
in-scope implicits when the current `Context`'s scope contains
a name-clashing entry.
Incidentally, this proved to be a shallow solution, and we later
improved shadowing detection in SI-4270 / 9129cfe9. That picked
up cases where a locally defined symbol in an intervening scope
shadowed an implicit.
This commit includes the test case from the comments of SI-2866.
Part of it is tested as a neg test (to test reporting of ambiguities),
and the rest is tested in a run test (to test which implicits are
picked.)
However, in the test case of SI-5639, we see that the scope lookup
performend by `isQualifyingImplicit` is fooled by a "ghost" module
symbol. The apparition I'm referring to is entered when
`initializeFromClassPath` / `enterClassAndModule` encounters
a class file named 'Baz.class', and speculatively enters _both_ a
class and module symbol. AFAIK, this is done to defer parsing the
class file to determine what inside. If it happens to be a Java
compiled class, the module symbol is needed to house the static
members.
This commit adds a condition that `Symbol#exists` which shines a torch
(forces the info) in the direction of the ghost module symbol. In our
test, this causes it to vanish, as we only need a class symbol for
the Scala defined `class Baz`.
The existing `pos` test for this actually did not exercise the bug,
separate compilation is required. It was originally checked in to
`pending` with this error, and then later moved to `pos` when someone
noticed it was not failing.
|
| |\ \ \
| | | |
| | | | |
SI-8534 Avoid crash in erroneous SelectFromTypeTree
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
PR #2374 changed the behaviour of `typedSingletonTypeTree` in the
presence of an error typed reference tree. It incorrectly
returns the reference tree in case on an error. However, this is
a term tree, which is an inconsistent result with the input type
tree. Consequently, a `typedSelectInternal` later fails when
using this as the qualifier of a `SelectFromTypeTree`.
Both test cases enclosed show this symptom.
This commit:
- Returns `tree` rather than `refTyped` when `refTyped` is
error typed or when it isn't suitable as a stable prefix.
- Avoids issuing a cascading "not a stable prefix" error if the
`refTyped` is error typed.
- Adds an extra layer of defense in `typedSelectFromTypeTree`
to bail out quickly if the qualifier is error typed.
The last measure is not necessary to fix this bug.
|
| |\ \ \
| |/ /
|/| | |
[sammy] eta-expansion, overloading, existentials
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't naively derive types for the single method's signature
from the provided function's type, as it may be a subtype
of the method's MethodType.
Instead, once the sam class type is fully defined, determine
the sam's info as seen from the class's type, and use those
to generate the correct override.
```
scala> Arrays.stream(Array(1, 2, 3)).map(n => 2 * n + 1).average.ifPresent(println)
5.0
scala> IntStream.range(1, 4).forEach(println)
1
2
3
```
Also, minimal error reporting
Can't figure out how to do it properly, but some reporting
is better than crashing. Right? Test case that illustrates
necessity of the clumsy stop gap `if (block exists (_.isErroneous))`
enclosed as `sammy_error_exist_no_crash`
added TODO for repeated and by-name params
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a class contains a double defintion of a method that overrides
an interface method, LUBs could run into a spot where filtering
overloaded alternatives to those that match the interface method
fails to resolve to a single overload, which crashes the compiler.
This commit uses `filter` rather than `suchThat` to avoid the crash.
|
| |\ \ \
| |/ /
|/| | |
SI-5091 Move named-args cycle test from pending to neg
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
There is a typechecking cycle, and since 4669ac180e5 we now report
this in a clearer manner.
Once we change the language to unconditionally interpret an
assignent in argument position as a named argument would be the
only way to get this over to `pos`.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When typechecking the primary constructor body, the symbols of
constructor parameters of a class are owned by the class's owner.
This is done make scoping work; you shouldn't be able to refer to
class members in that position.
However, other parts of the compiler weren't so happy about
this arrangement. The enclosed test case shows that our
checks for invalid, top-level implicits was spuriously triggered,
and implicit search itself would fail.
Furthermore, we had to hack `Run#compiles` to special case
top-level early-initialized symbols. See SI-7264 / 86e6e9290.
This commit:
- introduces an intermediate local dummy term symbol which
will act as the owner for constructor parameters and early
initialized members
- adds this to the `Run#symSource` map if it is top level
- simplifies `Run#compiles` accordingly
- tests this all in a top-level class, and one nested in
another class.
|
| |
|
|
|
|
|
| |
When buffering, we must report the ambiguity error to avoid a stack overflow.
When the error refers to erroneous types/symbols,
we don't report it directly to the user,
because there will be an underlying error that's the root cause.
|
| |\
| |
| | |
SI-8731 warning if @switch is ignored
|
| | |
| |
| |
| |
| | |
For matches with two or fewer cases, @switch is ignored. This should
not happen silently.
|
| |\ \
| | |
| | | |
SI-7746 fix unspecifc non-exhaustiveness warnings and non-determinism in pattern matcher (2.11)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes non-determinism within the DPLL algorithm and disallows
infeasible counter examples directly in the formula.
The function to compute all solutions was flawed and thus only
returned a subset of the solutions. The algorithm would stop too soon
and thus depending on the ordering of the symbols return more or less
solutions. I also added printing a warning when the search was stopped
because the max recursion depth was reached. This is very useful as an
explanation of spuriously failing regression tests, since less counter
examples might be reported. In such a case the recursion depth should
be set to infinite by adding `-Ypatmat-exhaust-depth off`.
The mapping of the solutions of the DPLL algorithm to counter examples
has been adapted to take the additional solutions from the
solver into account:
Consider for example `t8430.scala`:
```Scala
sealed trait CL3Literal
case object IntLit extends CL3Literal
case object CharLit extends CL3Literal
case object BooleanLit extends CL3Literal
case object UnitLit extends CL3Literal
sealed trait Tree
case class LetL(value: CL3Literal) extends Tree
case object LetP extends Tree
case object LetC extends Tree
case object LetF extends Tree
object Test {
(tree: Tree) => tree match {case LetL(CharLit) => ??? }
}
```
This test contains 2 domains, `IntLit, CharLit, ...` and `LetL, LetP, ...`,
the corresponding formula to check exhaustivity looks like:
```
V1=LetC.type#13 \/ V1=LetF.type#14 \/ V1=LetL#11 \/ V1=LetP.type#15 /\
V2=BooleanLit.type#16 \/ V2=CharLit#12 \/ V2=IntLit.type#17 \/ V2=UnitLit.type#18 /\
-V1=LetL#11 \/ -V2=CharLit#12 \/ \/
```
The first two lines assign a value of the domain to the scrutinee (and
the correponding member in case of `LetL`) and prohibit the counter
example `LetL(CharLit)` since it's covered by the pattern match. The
used Boolean encoding allows that scrutinee `V1` can be equal to
`LetC` and `LetF` at the same time and thus, during enumeration of all
possible solutions of the formula, such a solution will be found,
since only one literal needs to be set to true, to satisfy that
clause. That means, if at least one of the literals of such a clause
was in the `unassigned` list of the DPLL procedure, we will get
solutions where the scrutinee is equal to more than one element of the
domain.
A remedy would be to add constraints that forbid both literals
to be true at the same time. His is infeasible for big domains (see
`pos/t8531.scala`), since we would have to add a quadratic number of
clauses (one clause for each pair in the domain). A much simpler
solution is to just filter the invalid results. Since both values for
`unassigned` literals are explored, we will eventually find a valid
counter example.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This pattern of code is typically a bug:
if (f(tp.typeSymbol)) {
g(tp.typeArgs)
}
Intead, one needs to take the base type of `tp` wrt `tp.typeSymbol`.
This commit does exactly that when formatting the `@implicitNotFound`
custom error message.
Patch found on the back of an envelope in the handwriting of @adriaanm
|
| |\ \ \
| | | |
| | | | |
SI-8217 allow abstract type members in objects
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, abstract type members were allowed in objects only when inherited,
but not when declared directly. This inconsistency was not intended. In dotty,
abstract type members are allowed in values and represent existentials; so upon
discussion, it was decided to fix things to conform to dotty and allow such type
members. Adriaan also asked to keep rejecting abstract type members in methods
even though they would conceivably make sense.
Discussions happened on #3407, scala/scala-dist#127.
This code is improved from #3442, keeps closer to the current logic, and passes tests.
Existing tests that have been converted to `pos` tests show that
this works, and a new test has been added to show that local
aliases (ie term-owned) without a RHS are still rejected.
|
| | |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When type checking an type application, the arguments are allowed
to be of kinds other than *. This leniency is controlled by the
`ContextMode` bit `TypeConstructorAllowed`.
(More fine grained checking of matching arity a bounds of type
constructors is deferred until the refchecks phase to avoid
cycles during typechecking.)
However, this bit is propagated to child contexts, which means
that we fail to report this error in the lexical context marked
here:
T[({type x = Option}#x)]
`-------------'
This commit resets this bit to false in any child context
relates to a different tree from its parent.
|
| | |/
|/|
| |
| |
| |
| | |
The check file used to contain a stack trace entry from
Predef with a line number. I've made the macro fail
in a different manner that avoids this fragility.
|
| |\ \
| |/
|/| |
SI-8806 Add lower bound check to Any lint
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already exclude the lint check for infer-any if
Any is somewhere explicit.
This commit adds lower bounds of type params to
the somewheres.
Motivated by:
```
scala> f"${42}"
<console>:8: warning: a type was inferred to be `Any`; this may indicate a programming error.
f"${42}"
^
res0: String = 42
```
|
| | |
| |
| |
| | |
Compiler internals treat lazy vals as methods. Therefore, we need to have a special case for them when assembling the warning message.
|
| |\ \
| | |
| | | |
SI-8764 fix return type of case class productElement under Xexperimental
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Xexperimental
Under Xexperimental, productElement now returns the lub instead
of the weak lub of case class parameter types (numeric widening
shouldn't magically happen *inside* productElement).
This was removed from 2.12.x in 6317ae2.
|
| |\ \ \
| | | |
| | | | |
SI-8498 @compileTimeOnly should be aware of bridge methods.
|
| | | |/
| |/|
| | |
| | |
| | |
| | | |
Calling a @compileTimeOnly method from another @compileTimeOnly
method happens when the former gets a bridge method. It should not
throw an error. Calling the bridge or the method will anyway.
|
| |\ \ \
| | | |
| | | | |
SI-5691 lint warning when a type parameter shadows an existing type.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds a new lint warning for when a class/method/type-member's
type parameter shadows an existing type: `-Xlint:type-parameter-shadow`.
It excludes type parameters of synthetic methods (the user can't
rename or remove those anyway), otherwise, for example, every case class
triggers the warning.
Also fixes a test that contained wrong java sources (that didn't even
compile...), discovered thanks to the warning.
---
This kind of errors shows up every now and then on the mailing-list, on
stackoverflow, etc. so maybe a warning would be useful.
I was afraid this would yield too many warnings for libraries that are
heavy on type parameters, but no: running this on scalaz and shapeless
HEAD (`v7.1.0-RC1-41-g1cc0a96` and `v2.0.0-M1-225-g78426a0` respectively)
yields 44 warnings. None of them are false positives; they usually come
from:
- scalaz loving using `A` as type parameter, even several levels deep
of parametrized classes/methods
- or calling a type parameter that will hold a map `Map`, or similar,
thus shadowing an existing type
|
| |\ \ \ \
| |_|/ /
|/| | | |
part 2 of the big error reporting refactoring
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reporting mode used to be governed by contextMode.
This logic is left in place by this commit, and the consistency
of the new and the old is checked. Will be removed in follow-up commit.
The main difference is that we no longer throw TypeErrors in buffering mode.
There was one instance of context.error in implicit search the exploited the
fact that implicit search runs in buffering (silent) mode and thus calls to
error(pos,msg) used to throw new TypeError(pos, msg) -- made this explicit,
and removed throwing behavior from the buffering context reporter.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The two functional differences are:
- always add the diagnostics string
- check erroneousness in `issueAmbiguousTypeErrorUnlessErroneous`,
before even constructing the error message.
Consider this nugget:
```
- def issueAmbiguousError(pre: Type, sym1: Symbol, sym2: Symbol, err: AbsTypeError) {
- issueCommon(err) { case _ if ambiguousErrors =>
- if (!pre.isErroneous && !sym1.isErroneous && !sym2.isErroneous)
```
I'd like to state for the record that the if-erroneous in the
case of the partial function looked super-dodgy: it meant that,
when `ambiguousErrors`, `issueCommon` would not get to the `else` branches
that buffer or throw, and if the erroneous condition was met,
nothing would be issued/buffered/thrown.
This refactoring checks this condition up front.
|
