| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The parent commit works around a particular problem that led to a compiler
freeze in SI-8158, whereas this commit introduces a general solution -
a cache that tracks all types that we've recursed into during printing.
I can't immediately come up with an example of a type that would be caught
by this safety net, but unknown unknowns are the worst of them all, so why not
guard against them while we can.
|
| |\ \ \
| |_|/
|/| | |
Fix non-deterministic <:< for deeply nested types
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the interests of keeping subtyping decidable [1], 152563b
added some bookkeeping to `isSubType` to detect cycles.
However, this was based on a hash set containing instances of
`SubTypePair`, and that class had inconsistencies between its
`hashCode` (in terms of `Type#hashCode`) and `equals`
(in terms of `=:=`).
This inconsistency can be seen in:
scala> trait C { def apply: (Int @unchecked) }
defined trait C
scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType
intUnchecked: $r.intp.global.Type = Int @unchecked
scala> val p1 = new SubTypePair(intUnchecked, intUnchecked)
p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked
scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations)
p2: $r.intp.global.SubTypePair = Int <:<? Int
scala> p1 == p2
res0: Boolean = true
scala> p1.hashCode == p2.hashCode
res1: Boolean = false
This commit switches to using `Type#==`, by way of the standard
case class equality.
The risk here is that you could find a subtyping computation that
progresses in such a manner that we don't detect the cycle. It would
need to produce an infinite stream of representations for types that
were `=:=` but not `==`. If that happened, we'd fail to terminate,
rather than judging the relationship as `false`.
[1] http://research.microsoft.com/pubs/64041/fool2007.pdf
|
| |\ \
| | |
| | | |
reshuffles names for blackbox/whitebox contexts, changes bundle notation
|
| | |/
| |
| |
| |
| |
| | |
Adjusts bundle notation to read `class Bundle(val c: Context)` instead of
`class Bundle extends Macro`. This avoids calling compileLate in the
macro compiler and associated tooling problems.
|
| |\ \
| |/
|/| |
SI-8058 Better support for enum trees
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Replace the approach of “detect some magic combination of flags to
trigger some action” by introducing an enum flag which makes the
semantics and the intentions of the code using it more explicit.
This basically involves wiring up the existing ACC_ENUM bit to a new
modifier flag and making sure it is set correctly when encountering
enums.
The existing enum tests files/pos/t5165 and files/pos/t2764 keep
working, showing that this hasn't introduced any obvious regressions.
Tests for the changes in Namer which prevent scalac from messing with
enum trees can't be added yet, because one currently can't define an
enum in Scala without the help of the macro paradise.
The intention is to add the @enum macro as a full test suite as soon
as one can depend on macro annotations.
One might wonder why we don't check for
clazz.superClass == JavaEnumClass (where clazz is the owning class)
in isEnumConstant.
The reason is that this causes illegal cyclic reference error.
Explanation by Eugene why this happens:
(23:17:52) xeno_by: so here's what happens as far as I can understand at 11pm :)
(23:18:09) xeno_by: scalac tries to complete the signature of the newly expanded class
(23:18:11) xeno_by: to do that
(23:18:40) xeno_by: to do that it needs three things
(23:18:51) xeno_by: because the signature of a class is ClassInfoType which consists of three things
(23:19:05) xeno_by: parents
(23:19:08) xeno_by: decls
(23:19:09) xeno_by: and symbol
(23:19:20) xeno_by: symbol is easy - it's already there
(23:19:30) xeno_by: parents are also easy
(23:19:39) xeno_by: you just typecheck the things that come after "extends"
(23:19:42) xeno_by: but decls are tricky
(23:19:51) xeno_by: scalac goes through all the members of the class
(23:20:03) xeno_by: and doesn't typecheck them... no, it doesn't
(23:20:07) xeno_by: it just enters them
(23:20:32) xeno_by: i.e. creates symbols for them and assigns lazy completers to those symbols so that if someone wants to know their signatures, they will go through the completers
(23:20:34) xeno_by: and then
(23:20:38) xeno_by: wait
(23:20:40) xeno_by: there's one but
(23:20:42) xeno_by: BUT
(23:20:47) xeno_by: while we enter those symbols
(23:20:53) xeno_by: our ClassInfoType is not ready yet
(23:21:09) xeno_by: the class we're completing is still considered to be in the middle of being completing
(23:21:12) xeno_by: so
(23:21:24) xeno_by: when inside enterSym you try to ask that class for its super class
(23:21:35) xeno_by: what happens is that check asks the class for its type signature
(23:21:45) xeno_by: the ClassInfoType that consists of parents and decls
(23:21:54) xeno_by: even though the parents are already calculated
(23:22:01) xeno_by: the ClassInfoType as a whole is not
(23:22:16) xeno_by: so scalac says that you're trying to complete something that's currently being completed
(23:22:20) xeno_by: cyclic reference error
(23:22:59) xeno_by: "cyclic" in English looks an awful lot like "суслик" in Russian (which means "gopher")
|
| |/
|
|
|
|
|
|
|
|
|
| |
One example were this would lead to subtle bugs otherwise is
Symbol_apply, where after erasure an overloaded symbol containing
Symbol#apply and UniquenessCache#apply is returned.
// findMember considered harmful after erasure; e.g.
//
// scala> exitingErasure(Symbol_apply).isOverloaded
// res27: Boolean = true
|
| |
|
|
|
|
| |
Namely:
1) Moved definitions of Liftable and Unliftable into a separate file.
2) Inlined internal names that were only used in StandardLiftables.
|
| |
|
|
|
|
|
|
|
|
| |
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 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.
|
| |
|
|
|
|
|
|
|
|
|
| |
1. refactor out FreshNameExtractor out of Quasiquotes cake into
SymbolTable (can’t put it outside due to the fact that names are
path-dependent)
2. add optional parameter to the fresh name creator to cover additional
qq$ prefix needed for quasiquotes
3. add unit tests
|
| |\
| |
| | |
[rebase] blackbox and whitebox macros
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding
Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.
For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html
Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
|
| | |
| |
| |
| |
| |
| | |
Encode values into real trees rather than non-tree case classes.
This is needed for re-usability of desugaring code between quasiquotes
and parser.
|
| |/
|
|
|
|
|
| |
Previously attachments weren't imported by importTree. Now a new marker
trait has been added that lets attachments to import themselves to the
new universe together with all their innards. Additionally a simpler
subtrait is defined to mark attachments that can be imported as-is.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.
This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.
In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.
The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.
The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are all used to calls to `definitions.PredefModule`, or
`defintions.Predef_???` to grab the symbol of some well known
entity. But you'll notice that some of these are lazy vals,
and others are defs.
Why is this so? In the presentation compiler, a member like
`Predef.???` will be assigned a new symbol after the user
browses into `Predef.scala`.
Mistakenly using vals in definitions leads to subtle
IDE bugs like SI-7678. We are able to trigger these
situations in tests, as noted in the comments of that issue.
Changing the vals to defs, on the other hand, has a performance
penalty. Some schemes to workaround this have shown up:
cache them per-implicit search, or compare method names and owners
rather than symbols on hot paths in the type checker.
This commit introduces a facility to cache these sort of symbols
per-run, and uses it to check for `Predef.conforms` and
and for the class/type tag materializers.
A followup pull request (WIP: https://github.com/retronym/scala/compare/ticket/7678-2)
will expand the use of to address the widespread and unsafe caching
of member symbols that I found while investigating SI-7678.
|
| |
|
|
|
|
|
|
|
| |
We do need lazy to be robust, because initialization sequence might
trigger synced operations in unexpected order, leading to NPE's.
Even if this is optimizable by removing some of the lazies or by
carefully reordering cake layers, there's no guarantee that all this
effort won't break after another reflection refactoring.
|
| |
|
|
| |
Fixes this glaring omission of synchronization for a core part of Symbol.info.
|
| |
|
|
| |
This is another optimization we discussed with Roland.
|
| |
|
|
|
|
|
|
| |
This is one of the changes suggested by Roland in order to reduce contention
caused by reflection GIL.
Locks optimized away here are indirectly used for such fundamental operations
as subtyping tests, so the optimization looks quite important.
|
| |
|
|
|
|
|
| |
On a serious note, I feel really uncomfortable about having to juggle
this slew of locks. Despite that I can't immediately find a deadlock,
I'm 100% sure there is one hiding in the shadows. Hence, I'm abandoning
all runtime reflection locks in favor of a single per-universe one.
|
|
|
The code to do so is curated with the help of a generator. Because this
needs to inspect code post-typer, the code generator is run during partest
as a code-validator. We could concievably do the same with a macro, but
this approach might be a better starting point which macros continue to
stabilize.
Removes Definitions.AnyRefModule and an already deprecated alias, as
these have been throwing exceptions for more than a year since 6bb5975289.
They used to be used by AnyRef specialization.
|
