| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor to reduce the Reporter interface. Working towards
minimal interfaces in scala.reflect.internal that can be consumed by sbt/IDE/....
The scala.tools.nsc package is entirely private to the compiler (in principle).
A `Reporter` should only be used to inform (info/warning/error). No state.
Ideally, we'd move to having only one reporter, whose lifetime is adjusted
appropriately (from per-run in general to per-context for type checking,
so errors can be buffered -- "silenced" -- during nested type checking calls).
Start the clean up by moving truncation to the REPL,
since it's not relevant for regular reporting. Perversely, we were checking
truncation all the time, even though it's only on during a repl run.
(Truncation is now always turned off in the repl under -verbose.)
Untangle error resetting on symbols from error reporting (reportAdditionalErrors).
This fixes a nice&subtle bug that caused feature warnings to be suppressed under
`-Xfatal-warnings`:
```
def reportCompileErrors() {
if (!reporter.hasErrors && reporter.hasWarnings && settings.fatalWarnings)
globalError("No warnings can be incurred under -Xfatal-warnings.")
if (reporter.hasErrors) { ... }
else {
// will erroneously not get here if
// `reporter.hasWarnings && settings.fatalWarnings`
// since the `globalError` call above means `reporter.hasErrors`...
allConditionalWarnings foreach (_.summarize())
...
}
}
```
The second `if`'s condition depends on the `globalError` call in the first `if`...
|
| |\
| |
| | |
SI-8675 Avoid unreported error after second try using implicit view
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As reported on scala-internals. After tightening up the treatment
of undetermined type parameters in SI-7944, the enclosed test
case no longer typechecks. And since the regression fixed in the
previous commit, the error was swallowed by the typechecker only
to be burped up by a crash in the backend.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is specific to situations in which we first typecheck an
application `qual.m(arg)` against the method `m` directly provided
by `qual`, and then fall back to `implicitView(qual).m(arg)`.
Regressed in SI-3971 / 7fa77af, in which error reports were moved
to the innermost `Apply`, and the check for `errorInResult` was
accordingly changed to recurse through `Apply` trees.
Before that change, we did not fall back to using a view. After the
change, we do try a view. We retypecheck the arguments under the
`retyping` mode (see `tryTypedArgs`), but this doesn't seem to
be enough to avoid leaking the error typed nested trees from the
first try.
Here's an example from the enclosed test case:
a.update(0, x[A]({new isString(true)}))
`-- error typed
refArrayOps(a).update(0, x[A]({new isString(true)}))
` `-- error type persists
`-- this tree is retypecked by tryTypedArgs
This commit changes `onError` to only proceed with the second
try if the retyped argument trees are error free.
|
| |\ \
| | |
| | | |
SI-8657 don't miss tailrec defs in more positions
|
| | |/
| |
| |
| |
| |
| |
| | |
1) First operand of boolean expression using `&&` or `||`. Second operands of
those boolean exprs were already treated specially here but handling for first
operands was missing.
2) Condition of `If`. Also added a test for guards.
|
| |\ \
| |/
|/| |
SI-8185 Correct grammar for single-warning compilation run
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Enumerate the subtypes of sealed parent types of refinement
types, and filter those that conform to the refinement type.
Such types can crop up easily when LUB-bing case classes which
add `Product with Serializable` to the mix.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
One more EOL crasher, or lack-of-EOL crasher, when the text
is at EOF.
It was not caught by the last round of excellent and
thorough tests because
```
// If non-whitespace tokens run all the way up to EOF,
// positions go wrong because the correct end of the last
// token cannot be used as an index into the char array.
// The least painful way to address this was to add a
// newline to the array.
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Where N is the number of members of the enclosing package.
Double definition errors for top level classes/objects are issued
elsewhere, as demonstrated by the enclosed test. So we can
omit the call to `checkNoDoubleDefs` in this content.
We can't omit the call to `addSynthetics` for package
class owners (case- and value-class synthetic companions
are added here), but we can make the process cheaper by
moving the expensive-but-usually-true call to `shouldAdd`.
Here's an example of the improvement.
% rm -rf /tmp/pkg; (for i in {1..50}; do for j in {1..100}; do echo "package pkg { class A_${i}_${j}___(val a: Int, val b: Int) }"; done; done) > sandbox/A1.scala && time scalac-hash v2.11.0 -Ybackend:GenASM -J-Xmx1G -J-XX:MaxPermSize=400M -d /tmp sandbox/A1.scala;
real 0m49.762s
user 1m12.376s
sys 0m2.371s
% rm -rf /tmp/pkg; (for i in {1..50}; do for j in {1..100}; do echo "package pkg { class A_${i}_${j}___(val a: Int, val b: Int) }"; done; done) > sandbox/A1.scala && time qbin/scalac -Ybackend:GenASM -J-Xmx1G -J-XX:MaxPermSize=400M -d /tmp sandbox/A1.scala;
real 0m35.662s
user 0m58.275s
sys 0m2.355s
We've still got another source of pathological performance in
creating nested scopes that I'll fix in the next commit.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
The test case demonstrates that this is important for serialization
and for strictfp. (Although the latter is still pretty broken,
see SI-7954.)
Now that the synthetic subclass of `Tuple2[Int, Int]` also has the
`@deprecatedInheritance` annotation, I had to change the spot that
issues this warning to be silent after the typer phase. Otherwise,
we get two warnings in `run/t3888.scala`. This also remedies double
warnings that were incurred in `neg/t6162-inheritance`.
|
| |\
| |
| | |
SI-8546 Pattern matcher analysis foiled by over-widening
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
In the enclosed test, the prefix checkable type
`ModuleTypeRef(F2.this, C)` was being inadvertently widened to
`ModuleTypeRef(F2[?], C)`. This started after some misguided
future-proofing in SI-6771 / 3009916.
This commit changes the `dealiasWiden` to a `delias`.
|
| |\ \
| | |
| | | |
SI-8549 Serialization: fix regression with @SerialVersionUID / start enforcing backwards compatibility
|
| | |/
| |
| |
| |
| |
| |
| | |
The `neg` test was already working since `SerialVersionUID`
was changed to a `ClassFileAnnotation`; the `run` test only
started working since the recently preceding commit that
made a compensatory test in the backend.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to SI-5702 which enabled use of
`*` in infix notation in patterns.
Most of the work is in distinguishing infix from a
sequence pattern.
Also, do not take backticked star as the repeated
parameter marker in postfix position. That is,
`Int``*``` is not `Int*` -- I hope double-tick
renders as tick. There is not a special use case
except that backticks mean "I am an identifier, as
is, and not a keyword."
|
| |\
| |
| | |
SI-8463 Avoid unpositioned errors from search for views
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Ideally, I'd like to fix this using `saveErrors = false` here to
firewall the enclosing context from the ambiguiouty error encountered
during implicit search.
I originally proposed that patch as a fix for SI-8419 in
https://github.com/scala/scala/pull/3460 but withdrew from
that approach as I uncovered a deeper bug that meant that
we actually shouldn't have even been looking for views in
that case.
But, this runs into SI-8230 and these failures:
test/partest --update-check \
/Users/jason/code/scala/test/files/pos/t2504.scala \
/Users/jason/code/scala/test/files/pos/t4457_1.scala \
/Users/jason/code/scala/test/files/neg/t4457_2.scala
Turns out that typechecking the ostensible straight forward
application, `Array("abc")`, hinges on us leaking an ambiguity
error from `viewExists` to find a path through overload resolution!
This commit takes a tiny step forward by using `context.tree`
rather than `EmptyTree` as the argument to `inferImplicit`.
This avoids unpositioned type errors.
|
| |\ \
| | |
| | | |
SI-8430 Less non-determinism in patmat exhautiveness warnings
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Another mole whacked on the head by using `LinkedHashMap`.
Caution: `LinkedHashMap` doesn't preserve its runtime type if
you map through the generic interface. I've noted this gotcha as
SI-8434. I've structured this patch to enforce that concrete
collection with types, which is a good idea anyway.
My method to track this down was to place breakpoints in
`Hash{Map,Set}`.{foreach,iterator}` to see where that was
used from within pattern match translation. This approach was
drastically faster than my previous rounds of whack-a-mole.
The counter-examples are still a bit off; I'm going to merge
that aspect of this ticket with SI-7746, in which we've
pinpointed the culpable part of the implementation, but haven't
had success in fixing the bug.
|
| |\ \
| | |
| | | |
SI-8450 no "implicit numeric widening" in silent mode
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this fix, we get a second, spurious warning.
```
t8450.scala:5: warning: implicit numeric widening
def elapsed: Foo = (System.nanoTime - 100L).foo
^
t8450.scala:11: warning: implicit numeric widening
def elapsed: Foo = (System.nanoTime - 100L).foo
^
error: No warnings can be incurred under -Xfatal-warnings.
two warnings found
one error found
```
By respecting silent contexts, we now get only one.
I sneakily fixed similar occurrences without adding a test.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implicit search detects likely cycles by looking at the stack of
open implicits and checking the same implicit appears twice, and
if the second occurrence is trying satisfy an implicit search for
a "dominant" type.
Originally, this condition immediately failed the entire implicit
search. However, since Scala 2.10, this mechanism has been refined to
continue searching after the first divergent implicit is detected.
If a second divergence is found, we fail immediately. If the followup
search fails, we report the first divergence. Otherwise, we
take the successful result.
This mechanism was originally built around exceptions. This proved
to be fragile, and was refactored in SI-7291 / accaa314 to instead
use the `Context.errors` to control the process.
But, since that change, the pattern of implicits in scalanlp/breeze
and Shapeless have been prone to reporting the divergent implicit
errors where they used to recover.
So long as we left the `DivergentImplictTypeError` that originates
from a nested implicit search in `context.errors`, we are unable to
successfully typecheck other candidates. This commit instead
stashes the first such error away in `DivergentImplicitRecovery`,
to clear the way for the alternative path to succeed.
We must retain any other divergent implicit errors, as witnessed by
test/files/neg/t2031.scala, which loops unless we retain divergent
implicit errors that we don't stash in `DivergentImplicitRecovery`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In SI-7944 / 251c2b93, we discovered that typechecking of an implicit
candidate could leave orphaned undetermined type parameters in the
implicit search context. This resulted in naked type parameters
leaking into implicit expansions. The fix seemed easy: just copy
any symbols from `implicitSearchContext.undetparams` to the enclosing
context (other than ones in `SearchResult#subst`).
However, the test case in this ticket reveals a subtle flaw in that
fix: `implicitSerachContext.undetparams` only contains the type params
from the most recently typechecked candidate!
Why? Implicit search uses the same context to typecheck all plausibly
compatible candidates. The typechecking itself is driven by
`typedImplicit1`.
Side note, that explains the heisenbug behaviour noted in the ticket:
Not *all* plausibly implicit candidates are typechecked. If
the current 'best' eligible candidate is more specific than the next
candidate, we can skip that altogether.Implicit search actually
exploits this for performance by ordering the candidates according to
usage statistics. This reordering, means that commenting out lines
elsewhere in the file changed the behaviour!
This commit simply stores the undet. tparams in the `SearchResult`,
where it is safe from the vaguries of typechecking other candidates.
That makes `Test1` and `Test2` with in the enclosed test case fail
uniformly, both with each other, and with an explicit call to
the view.
This is ostensibly a regression from 2.10.3. To get there,
we need an implicit search that has to infer `Nothing` in a covariant
position. In 2.10.3, we would just let the `G` out into the wild,
which did the right thing for the wrong reasons.
|
| |\
| |
| | |
SI-4492 More informative error when class not found on classpath
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Position the error based on Select tree that failed to type check,
presumably due to an underlying MissingRequirementError, which has no position.
There are lots of other ways we could rewrap a MRE and supplement position info,
but that remains TODO. Jason's review comment is recorded in the code.
Also try to detect the case of a missing module and provide some advice,
as well as linking to the forthcoming 2.11 guide at
http://docs.scala-lang.org/overviews/core/scala-2.11.html.
|
| |/
|
|
|
|
|
| |
Issue deprecation warning under -Xsource:2.10 so time
travelers can have an authentic deprecation experience before
finding that their unsound code no longer compiles in 2.11.
The relevant ticket to the soundness issue is SI-6566.
|
| |
|
|
|
| |
`T*` rather than `<repeated>[T]`, as we alreday do for Scala repeated
parameters.
|
| |\
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
|
|
|
| |
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-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.
|
| |\ \
| | |
| | | |
SI-1503 don't assume unsound type for ident/literal patterns
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The fix only kicks in under -Xfuture. We also warn under -Xlint.
What type should a variable bound to the value matched by a pattern have?
To avoid CCEs, it should be a type that's implied by the matching
semantics of the pattern.
Usually, the type implied by a pattern matching a certain value
is the pattern's type, because pattern matching implies instance-of checks.
However, Stable Identifier and Literal patterns are matched using `==`,
which does not imply a type for the binder that binds the matched value.
The change in type checking due to this fix is that programs that used to crash with a CCE
(because we blindly cast to the type of the pattern, which a `==` check does not imply)
now get a weaker type instead (and no cast). They may still type check, or they may not.
To compensate for this fix, change `case x@Foo => x` to `case x: Foo.type => x`,
if it's important that `x` have type `Foo.type`.
See also:
- SI-4577: matching of singleton type patterns uses `eq`,
not `==` (so that the types are not a lie).
- SI-5024: patmat strips unused bindings, but affects semantics
|
| |\ \ \
| | | |
| | | | |
SI-8321 bundles can't be whitebox
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Given the recent glaring oversight in macro bundles, I have to have more
tests in order to make sure that things are going to work as they should.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
At the moment, bundle selection mechanism is pretty picky. If a candidate
bundle's parameter isn't either blackbox.Context, whitebox.Context or
PrefixType refinement thereof, then it's not a bundle and the user
will get a generic error.
However we can be a bit more helpful and admit classes that are almost
like bundles (looksLikeMacroBundleType), have them fail isMacroBundleType,
and then emit a much prettier error message to the user that would tell them
that bundles must be monomorphic and their sole parameter should not just
be any subtype of blackbox.Context or whitebox.Context.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's not like they were inducing bugs, but I can't see how polymorphism
can be useful for macro bundles, hence imho it's better to reduce the
number of degrees of freedom of the system.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Vanilla macros only allow blackbox.Context, whitebox.Context and
PrefixType refinements thereof. Bundles should behave in the same way.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
whitebox.Context <: blackbox.Context, so in order to check for blackboxity
it's not enough to check whether the context used is <: blackbox.Context.
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-5479 deprecate DelayedInit outside of App
|
| | | | | |
|
