| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
streamlines refchecking undesired symbol properties
|
| | |
| |
| |
| |
| |
| | |
Unifies `checkDeprecated`, `checkMigration` and `checkCompileTimeOnly`
into a single centralized point of reference that is now consistently
called from `checkTypeRef`, `transformIdent` and `transformSelect`.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the new focus on quasiquotes in macro implementations, we now have
to change the way how inference of macro def return types works.
Previously, if the return type of a macro def wasn’t specified, we looked into
the signature of its macro impl, took its return type (which could only
be c.Expr[T]) and then assigned T to be the return type of the macro def.
We also had a convenient special case which inferred Any in case when
the body of the macro impl wasn’t an expr. That avoided reporting spurious
errors if the macro impl had its body typed incorrectly (because in that
case we would report a def/impl signature mismatch anyway) and also provided
a convenience by letting macro impls end with `???`.
However now we also allow macro impls to return c.Tree, which means that
we are no longer able to do any meaningful type inference, because c.Tree
could correspond to tree of any type.
Unfortunately, when coupled with the type inference special case described
above, this means that the users who migrate from exprs to quasiquotes
are going to face an unpleasant surprise. If they haven’t provided
explicit return types for their macro defs, those types are going to be
silently inferred as `Any`!
This commit plugs this loophole by prohibiting type inference from
non-expr return types of macro impls (not counting Nothing). Moreover,
it also deprecates c.Expr[T] => T inference in order to avoid confusion
when switching between exprs and quasiquotes.
|
| |\
| |
| | |
add method dequeueOption to immutable.Queue
|
| | |
| |
| |
| |
| |
| | |
This allows immutable.Queue to be used conveniently in functional code.
Method is in the spirit of `headOption` on seqs or `get` on maps. Also
adds a unit test for immutable.Queue.
|
| |\ \
| | |
| | | |
SI-8013 Nowarn on macro str interpolation
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When warning about stray "foo $bar" under `-Xlint`,
which may be missing an interpolator id, suppress
the warning if we're in the middle of a macro
expansion, since we have no useful heuristic to
apply to the expanded tree.
The test for whether the string is part of an
expanded tree is to check all open macros for
an expanded tree that contains the literal tree
under scrutiny. (This is deemed more paranoid
than looking for a macro application that is an
enclosing position.)
|
| |\ \ \
| | | |
| | | | |
Merge #3209 and 2.10.x to master
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/interactive/scala/tools/nsc/interactive/CompilerControl.scala
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The rationale for not keeping units loaded by default is that the more
units are loaded, the slower is background compilation. For instance, in
the Scala IDE for Eclipse (which uses the presentation compiler),
typechecking occurs every time the reconciler kicks-in (~500millis after
you stop typing), hence it is important that units are not kept loaded
unless strictly necessary (for some extra information about this, see
https://www.assembla.com/spaces/scala-ide/tickets/1001388)
While I agree that using a boolean argument (`keepLoaded`) for deciding
if a unit should be loaded isn't a great design, other methods in
`CompilerControl` also have a keepLoaded parameter, so at least we have
some consistency. For the future, I'm thinking we should be able to
remove the `keepLoaded` flag altogether, and change the implementation
of `askLoadedType` to preserve the same units loaded in the presentation
compiler before and after its execution. Basically, if you want a unit
to be kept loaded, you should call `askReload` first, and then
`askLoadedType`. However, to reduce impact, I think the changes carried
by this commit will help us estimate if the solution I just outlined is
viable (because `askLoadeType` won't be keeping units loaded by default,
which wasn't the case with the former implementation).
(While the patch was mostly contributed by @huitseeker, @dotta has edited the
commit message to preserve the comments in the PR
https://github.com/scala/scala/pull/3209)
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
test/files/jvm/scala-concurrent-tck.scala
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Origin: viktorklang@1bbe854
|
| | |\| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
src/compiler/scala/tools/nsc/interactive/Global.scala
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Otherwise we can think that `+` in `1 + BigInt(2)` refers
to a method in `Int`.
In general, this protects the IDE from observing results from
"exploratory" typing which is discarded as the compiler backtracks
to another possibility.
This protection subsumes the condition that checked for overloaded
types: presentation/t7458 now passes without this.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We shouldn't observe tree types under silent mode.
The enclosed test is a standalone version of `1 + BigInt(2)`,
a standard example of exploratory typing in Scala. Once we determine
that none of the `+` methods in `Int` accepts (possibly implicitly
coerced `BigInt`), we have to backtrack and look for a view from
`Int => { +(_: BigInt): ? }`.
The next commit will correct the problem.
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
targeted type-checked
When asking for targeted typecheck, the located tree may have overloaded types
is the source isn't yet fully typechecked (e.g., a select tree for an
overloaded method). This is problematic as it can lead to unknown 'hovers',
broken hyperlinking that suddenly starts working, unresolved ScalaDoc comments,
and similar, in the Scala IDE.
With this commit we are hardening the contract of `askTypeAt` to return the
same type whether the file was fully type-checked or targeted type-checked.
This is done by preventing the typechecker to stop too early if the `located`
tree has an overloaded type. Furthermore, I'm assuming that if `located.tpe`
is of type `OverloadedType`, by letting the compiler carry-on the typechecking,
the `located.tpe` will eventually be resolved to a non-overloaded type. Said
otherwise, I expect the targeted typechecking will always terminate (if my
reasoning isn't sound, please say so).
The test provided with this commit demonstrates the new behavior (the position
used to execute the test is resolved to the `foo` method's call). In fact,
before this commit, executing the test returned the following:
(x: Int, y: String)Unit <and> (x: String)Unit <and> (x: Int)Unit
Showing that the tree's type is an overloaded type. The ambiguity is fixed by
this commit, and in fact the test's output is now:
(x: Int)Unit
|
| | | |\ \ \
| | | | | |
| | | | | | |
teaches toolbox about -Yrangepos
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Unlike in master, in 2.10.x enabling -Yrangepos requires instantiating
Global with mixed in RangePositions trait.
Same story for toolboxes. Just setting Yrangepos is not enough - one
needs to mix in RangePositions into ToolboxGlobal. I didn’t know that
back then, so now I’m fixing the oversight.
The commit is marked as [nomaster], because -Yrangepos doesn’t need
special treatment in master.
|
| |\ \ \ \ \ \
| |_|_|_|_|/
|/| | | | | |
Remove parallel collection views and, with them, Gen*View
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- code that used to be inherited in *View is now inlined
- the `view` methods on `ParIteratoa` and `ParSeq` now
convert to sequential collections, and are deprecated
asking the user to do this explicitly in the future.
Should be largely source compatible with 2.10.x, on the assumption
that the removed classes, while being public, were internal
implementation details.
A few tests used now-removed classes to demonstrate compiler crashes.
I managed to confirm that after my decoupling, t4365 still exercises
the bug:
% qbin/scalac test/files/pos/t4365/*.scala
warning: there were 2 deprecation warning(s); re-run with -deprecation for details
one warning found
% scalac-hash 7b4e450 test/files/pos/t4365/*.scala
warning: there were 2 deprecation warning(s); re-run with -deprecation for details
one warning found
% scalac-hash 7b4e450~1 test/files/pos/t4365/*.scala 2<&1 | grep -i wrong
error: something is wrong: cannot make sense of type application
something is wrong: cannot make sense of type application
something is wrong: cannot make sense of type application
I didn't manage to do the same for specializes-sym-crash.scala,
and instead just made it compile.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
better error messages for various macro definition errors
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fixes SI-8014, regression in Vector ++ TraversableOnce.
|
| | | |_|_|_|_|/
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Now uses the cached copy instead of the exhausted iterator. Adds a JUnit
test for ++.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Diminished Tuple Confusion
|
| | | |_|_|/ / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Firstly, for `((a, b) => c): (Tuple2[A, B] => C)`, we currently
just offer "missing parameter type." Is something of a rite of
passage to know that you need `{ case (...)}`
This commit stops short DWIM, but does offer a diagnostic to guide
the user towards the supported way of destructuring a `Tuple` in
the sole argument of a `Function1`.
Secondly, another (less common?) way one might try to write a function
to destructure a single tuple argument is:
(((a, b)) => c)
The parser now matches offers a specific error message for this, and
points out the alternatives.
In both cases, we avoid offering syntactically invalid alternatives,
by detecting names that aren't valid as variable-patterns, and
falling back to generic "paramN" in the error message.
A handly utility function to sequence a list of options is liberated
from the pattern matcher for broader use.
|
| |\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | | |
SI-8023 Fix symbol-completion-order bug of type var patterns
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
- Make `WildCardType` kind polymorphic
- Factory methods for expected kinds. They are still just
`Type`-s, though.
- Check if the type parameter is initialized, rather than
its owner.
- Take advantage of these to cleanup `typedAppliedTypeTree`
TODO: is this comment totally accurate? If so, should we
refactor `Kind.FromParams(tparams)` to `Kind.Arity(tparams.length)`?
// @M: kind-arity checking is done here and in adapt,
// full kind-checking is in checkKindBounds (in Infer)
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Removing the `isComplete` check altogether leads to cycles in,
for instatnce, F-bound type parameters:
trait LSO[+A, +Repr <: LSO[A, Repr]] // error: illegal cyclic reference involving type Repr
But, I believe that we can (and must) eagerly initialize the type
parameter symbols if we are typechecking a pattern.
While this appeared to regress in 2.11.x, but the problem was in fact
dormant and was merely uncovered in the fix for SI-7756, 3df1d77fc.
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | | |
SI-8022 Backwards compatibility for Regex#unapplySeq
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The change in ce1bbfe / SI-6406 introduced overloads of
`unapplySeq` with wider static and dynmaic result types
than the now-deprecated alternative that accepted `Any`.
This is subtly source incompatible and the change was noticed
in Specs2.
This commit uses `List` as the static and runtime type for
the new overloads.
For consistency, the same is done for the new method added
in SI-7737 / 93e9623.
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
No longer support unreleased STARR.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
No functional changes -- in an effort to separate state from behavior.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Merge 2.10.x, and PR #3196, to master
|
| | |\ \ \ \ \
| | | |_|/ /
| | |/| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
merge/2.10.x-positions-to-master
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
test/files/neg/applydynamic_sip.check
- Changes two calls from `.endOrPoint` to `.point`. The latter
is safe in master for both `Range`- and `OffsetPosition`s
- Updates checkfiles with unrelated position changes (constructors)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously there occurred a NoPosition error when one asks for position
information in the AST because no positions were set to the trees
created during the transformation for updateDynamic calls. This commit
applies range positions to the trees in order to being able to highlight
them inside of the scala-ide.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously, there were no positions created for the tuples that are
generated while doing the transformation for an applyDynamicNamed call.
This led to an NoPosition error in scalac when one tries to show
position information in the AST. Furthermore, this simplifies semantic
highlighting in the scala-ide because no position information for color
ranges have to be created anymore.
|
| | | | |_|/
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The new positions are range positions that directly refer to the
beginning and the end of the method calls in the sources instead of
simply point to the beginning of the expression. This allows the
scala-ide to semantically highlight select- and applyDynamic method
calls, because it has only to traverse the tree and apply the color
ranges to the given position ranges.
This also fixes the position marker of an error messages related
to a wrong Dynamic method signature.
|
| | | |\ \ \
| | | | | |
| | | | | | |
Backport of
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Updates localeContext() to return the best context possible when there are none directly
associated with the given position. It happens when an expression cannot be
successfully typed, as no precise ContextTree covers the expression location, or if the
position is not inside any expression.
Adds corresponding tests
(cherry picked from commit 3028327e2a2b553b12ee45519413515c8aa0865f)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
(cherry picked from commit 3d55fe723f1af91f4d2db421f0e0965c583346dc)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Adds a new marker /*_*/ to trigger scope completion test.
Original type completion test oracles update for the tweaked output
(cherry picked from commit 9c7c66ff7907e3ab814f0f4375eeaf6cdd230d5e)
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The tree created during expansion of default arguments contained trees with the
wrong type of positions. Let's discuss this with an example. Below is the tree
generated for the `foo` method in the test class included in this commit.
Before this commit:
```
[54:94]def foo(): [58]Unit = <70:90>{
[70:79]<artifact> val qual$1: [70]Bar = [70:79][70:79][70:79]new [74:77]Bar();
[80]<artifact> val x$1: [80]Int = [80]qual$1.bar$default$1;
<70:90><70:83>qual$1.bar([80]x$1)
}
```
Now:
```
[54:99]def foo(): [58]Unit = <70:95>{
<70:84><artifact> val qual$1: [70]Bar = [70:84][70:84][70:84]new [74:77]Bar();
[85]<artifact> val x$1: [85]Int = [85]qual$1.bar$default$1;
<70:95>[84:88]qual$1.bar([85]x$1)
}
```
Here are the list of changes:
* The synthetic `qual$1` has a transparent position, instead of a range position.
* The new Select tree (i.e., `qual$1.bar`) should always have a range position,
because `selected` (i.e., the called method) is always visible in the source
(in fact, this is the whole point of the fix, we need a range position or
hyperlinking request from the Scala IDE won't work).
* The Block that contains the expanded default arguments is forced to have a
transparent position, as it never exist in the original source.
The tricky part of the fix is the position assigned to the new Select tree,
which needs to respect the range position's invariants. In the specific case,
we ought to make sure that range positions don't overlap. Therefore, the position
assigned to the new Select tree is computed by intersecting the original Select
position (i.e., `baseFun`'s position) and the original qualifier's position
(i.e., `qual`'s position).
If you take a closer look at the range positions assigned in the tree after this
commit, you'll notice that the range position of the `qual$1`'s rhs (i.e.,
[70:84]), and `qual$1.bar` (i.e., [84:88]) might seem to overlap, because the
former ends where the latter begins. However, this not the case because of the
range position's invariant 2, which states:
> Invariant 2: in a range position, start <= point < end
Hence, the above two positions aren't overlapping as far as the compiler is
concerned.
One additional aspect (that may look like a detail) is that we make sure to
never generate a position such that its start is after its end. This is why we
take the position with the smallest end point.
Furthermore, calling `withStart` would turn any position in a range position,
which isn't desiderable in general (and, even worse, this can lead to
generation of invalid positions - bad offsets - if the computation is performed
on offset positions). Hence, the position's computation is only performed when
both `baseFun` and `qual` positions are range positions. Indeed, I expect this to
be always the case if the compiler is started with -Yrangepos.
(cherry picked from commit 3009a525b58a4c7865ff524899b85518884ee5f7)
|
| | | |\ \ \
| | | | | |
| | | | | | |
[backport] SI-7776 post-erasure signature clashes are now macro-aware
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
"double definition: macro this and method that have same type after erasure"
This error doesn't make sense when macros are involved, because macros
expand at compile-time, where we're not affected by erasure. Moreover,
macros produce no bytecode, which means that we're safe from VerifyErrors.
|
| | | |\ \ \ \
| | | |/ / /
| | |/| | | |
Fix completion after application with implicit arguments
|
| | | |\ \ \ \
| | | | | | |
| | | | | | | |
SI-6546 InnerClasses attribute refers to absent class
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
private access for local companions
|
| | | |_|_|_|_|/
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We go through similar gymnastics to make companion implicits
work for local class/object pairings, so we ought to be consistent
when it comes to access
|
