| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
We were outputing a the unattractive `package package`;
now we opt for `package object pack`.
Under `-Ydebug`, we still go to the "accurate" mode of the
old `toString` implementation, which differentiates package objects
vs package object classes.
|
|
|
|
|
|
|
|
|
|
| |
`Symbol#owner` of an overloaded symbol doesn't necessarily correspond
to the owner of any of the alternatives, and as such it shouldn't
be used in error message.
neg/t8024.scala actually represents a progression since 2.10.3;
the ambiguity was not reported. I bisected the change to
https://github.com/scala/scala/pull/1554.
|
|
|
|
|
|
|
|
|
| |
The error is new in 2.11, but actually seems correct. It appeared
in 2.11.0-M4, more specifically, after
https://github.com/scala/scala/pull/1554
But, the error message itself is wrong, and suggests that a method
symbol has latched itself to an incorrect owner.
|
|\
| |
| | |
SI-8054 Fix regression in TypeRef rebind with val overriding object
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Regressed in 80767383fd / SI-7928
The condition added in that commit are necessary after refchecks but
poisonous before.
This still seems rather fragile: I wonder if `eliminateModuleDefs`
in `RefChecks` ought to flag the module symbol as `ARTIFACT` after
creating the accessor, so as to signal that it shouldn't be bound
anymore?
|
|\ \
| | |
| | | |
Introduce Unliftable for Quasiquotes (take #3)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Use (x1, x2): (T1, T2) instead of (x1: T1, x2: T2)
2. More detailed error message for improper function argument
3. Fix typo
4. Completely remove LiftableClass symbol from definitions
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Unliftable is a type class similar to existing Liftable that lets
users to extract custom data types out of trees with the help of
straightforward type ascription syntax:
val q“foo.bar(${baz: Baz})” = ...
This will use Unliftable[Baz] to extract custom data type Baz out of
a tree nested inside of the another tree. A simpler example would be
extracting of constant values:
val q”${x: Int} + ${y: Int}” = q”1 + 2”
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit performs a number of preliminary refactoring needed to
implement unliftable:
1. Replace previous inheritance-heavy implementation of Holes with
similar but much simpler one. Holes are now split into two different
categories: ApplyHole and UnapplyHole which correspondingly represent
information about holes in construction and deconstruction quasiquotes.
2. Make Placeholders extract holes rather than their field values. This
is required to be able to get additional mode-specific information
from holes (e.g. only ApplyHoles have types).
3. Bring ApplyReifier & UnapplyReifier even closer to the future where
there is just a single base Reifier with mode parameter.
Along the way a few bugs were fixed:
1. SI-7980 SI-7996 fail with nice error on bottom types splices
2. Use asSeenFrom instead of typeArguments in parseCardinality.
This fixes a crash if T <:< Iterable[Tree] but does not itself
have any type arguments.
3. Fix spurious error message on splicing of Lists through Liftable[List[T]]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit introduces internal attachment that allows unapply macros to
be aware of their sub patterns and tweak their expansion depending
on that info.
At the moment this is not possible due to the way pattern macros are
expanded:
case MacroPat(inner1, inner2) => ...
During type checking this will expand as
MacroPat.unapply(<unapply-dummy>)
Meaning that macro can’t see inner1 and inner2 in it’s macroApplication.
To circumvent this we attach that info as an attachment to the dummy.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we believed that having Liftable outside of the Universe will
bring some advantages but it turned out this wasn’t worth it. Due to
infectious nature of path dependent types inside of the universe one
had to cast a lot. A nice example of what I’m talking about is a change
in trait ArbitraryTreesAndNames.
Additionally a number of standard Liftables is added for types that are
available through Predef and/or default scala._ import: Array, Vector,
List, Map, Set, Option, Either, TupleN.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously trees that represent parameters, case clauses and
type variables had strictly defined ValDef, TypeDef and CaseDef
types which caused problems in compositionality.
Now this checks are moved to runtime so it's possible to pass
a tree that is CaseDef but has Tree type.
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously it also matched other nodes but returned Nil as value of xs.
This behavior was added for sake of consistentcy with q”f[..$ts]”. On
the other hand q”f[..$Nil]” == q”f” but q”f(..$Nil)” == q”f()” not q”f”.
Due to this deconstruction/construction symmetry was broken.
On the other hand applications also have q"f(...$xss)" option which is
infact similar to q"f[..$ts]". Splicing Nil into it also results in q"f".
|
|\ \
| | |
| | | |
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`.
|
|\ \ \
| |/ /
|/| | |
deprecates macro def return type inference
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.)
|
|\ \ \ \
| | | | |
| | | | | |
undeprecates c.parse
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We never thought that c.parse is going to be completely subsumed by
quasiquotes, but hoped that the use cases that are going to be lost
aren’t going to be noticed by anyone.
Unfortunately, this isn’t the case, so I’m undeprecating c.parse until
we get a better story for those for whom quasiquotes are not enough.
|
|\ \ \ \
| | | | |
| | | | | |
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
|
| | |\ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6913 Reapplies a lost fix by @viktorklang
|
| | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | | |
Origin: viktorklang@1bbe854
|
| |\| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
src/compiler/scala/tools/nsc/interactive/Global.scala
|
| | |\ \ \ \ \
| | | |/ / / /
| | |/| | | | |
askTypeAt returns the same type for full/ targeted typecheck (2.10.x)
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | |\ \ \ \ \
| | | |/ / / /
| | |/| | | | |
Corrects positions for Dynamic calls
|
|\ \ \ \ \ \ \
| |_|_|_|_|/ /
|/| | | | | | |
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.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In 2.12, this gives us the option to move the code from
Gen*View down into *View. If we don't do something more
drastic with views, which inertia and history suggests
is a real possibility, we can at least shed a little of
the implementation.
These abstractions are *only* used to share implementation;
there is no `view` method available on, for instance, `GenSeq`
that lets one abstract over parallel/sequential collections
while spawning views.
scala> (List(1): collection.GenSeq[Int]).view
<console>:8: error: value view is not a member of scala.collection.GenSeq[Int]
(List(1): collection.GenSeq[Int]).view
^
Let's keep it that way.
I suspect that views over parallel collections exist not because
they were the most sought after feature, but rather because the
initial incarnatin of parallel collections used to live undernead
TraversableOnce, and hence were obligated to implement `def view`.
This change will give us deprecation warnings in the non deprecated
places that extend `Gen*View` (three, by my count) in the interim.
There are ways to avoid this, but they aren't particularly appealing.
|
|\ \ \ \ \ \ \
| |_|_|_|_|_|/
|/| | | | | | |
Use -Dupdate.versions to update versions.properties
|