| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-8224 Fix regression in f-bound aware LUBs
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Disable the heuristic approach to recursive bounds unless
the compiler is running under `-Xstrict-inference`.
[the above was not authored by the original author]
In db46c71e88, steps were taken to avoid blowing up in the
pathological LUB calculation needed for:
def trav = List(List(), Stream())
This skipped a level in the base class sequence when f-bounds
were detected at the current level.
In that example, when `lublist` was about to:
mergePrefixAndArgs(
typeOf[LinearSeqOptimized[A, List[A]]],
typeOf[LinearSeqOptimized[A, Stream[A]]],
)
If it proceeded (as in 2.10.3), the LUB is invalid:
error: type arguments [B[_ >: D with C <: B[_ >: D with C <: A]],s.c.immutable.LinearSeq[B[_ >: D with C <: A]] with s.c.AbstractSeq[B[_ >: D with C <: A]] with s.c.LinearSeqOptimized[B[_ >: D with C <: A],s.c.immutable.LinearSeq[A] with s.c.AbstractSeq[A] with s.c.LinearSeqOptimized[A,Immutable with Equals with java.io.Serializable] with java.io.Serializable] with java.io.Serializable] do not conform to trait LinearSeqOptimized's type parameter bounds [+A,+Repr <: s.c.LinearSeqOptimized[A,Repr]]
To avoid this, the added code would skip to the first non-F-bounded
base type of the same arity of each element in the list. This would
get to:
LinearSeqLike[D, Stream[D]]
LinearSeqLike[C, List[C]]
which are lubbable without violating the type constraints.
I don't think this was the right remedy. For starters, as seen in
this bug report, SI-8224, if the list of types are identical we
have let a perfectly good lub slip through our fingers, and end up
calculating too general a type.
More generally, if the type arguments in f-bounded positions coincide,
we don't risk calculating a ill-bounded LUB.
Furthermore, the code was widening each of the types separately;
this isn't something we want to do within `if (isUniformFrontier)`.
AFAICT this was just wasteful and as all `ts0` start with the same
type symbol, so `typeConstructorList` should be uniform.
This commit restricts this base-class skipping to situations where
the argument inferred for an type argument that is used as an f-bound
is not:
a) an existential (as created by `mergePrefixAndArgs` in invariant
positions.), or
b) equivalent to one of the corresponding input type arguments
(this is the case that fixes the regression in pos/8224.scala)
|
| |\ \
| | |
| | | |
CodePrinter added to Printers 2.11.0
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
flags metadata printing added
|
| | | |
| | |
| | |
| | |
| | |
| | | |
TypedTreesPrinter added
changes based on pull request comments:
print root packages flag; tests for syntactics; SyntacticEmptyTypeTree added to Printers
|
| |\ \ \
| | | |
| | | | |
Small Predef cleanup
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
Rename `conforms` to `$conforms` and put in a minimal backstop: pos/t7788.scala
TODO: predicate the backwards compatibility shim for `Predef_conforms`
on `-Xsource:2.10`
|
| | |/
|/|
| |
| |
| |
| | |
Even though quasiquotes are whitebox macros their
return values are in fact always trees. This might
help IDEs with macro expansions turned off.
|
| |\ \
| |/
|/| |
SI-8063 and its seventy friends
|
| | |
| |
| |
| |
| |
| |
| | |
As per Jason's feedback, these are now undeprecated, being aliases for
info and infoIn. I haven't touched the newly introduced setInfo family of
methods, because I think that on internal level we don't need setTypeSignature
anyway.
|
| | |
| |
| |
| |
| |
| |
| | |
Symbol.typeSignature and Symbol.typeSignatureIn no longer auto-init.
Neither does Symbol.toString (something that I introduced a few commits ago).
However Type.toString still does, and that should be enough to get
robust prettyprinting with minimal risk. Details are in comments.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is extremely important to enable cross-versioning Scala 2.10 codebases
against Scala 2.11 using Jason's trick with:
// TODO 2.11 Remove this after dropping 2.10.x support.
private object HasCompat { val compat = ??? }; import HasCompat._
def impl(c: Context)(...): ... = {
import c.universe._
import compat._
...
}
|
| | |
| |
| |
| |
| | |
Unfortunately I have to revert b017629 because of SI-8303. There are projects
(e.g. slick) that use typeOf in annotations, which effectively means bye-bye.
|
| | |\ |
|
| | |\ \ |
|
| | | | | |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/compiler/scala/reflect/macros/compiler/Resolvers.scala
src/compiler/scala/reflect/macros/contexts/Typers.scala
src/compiler/scala/tools/reflect/ToolBoxFactory.scala
src/reflect/scala/reflect/api/BuildUtils.scala
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Again, thanks to sbt.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now when we have internal.decorators, it is reasonable to advertise them
to the users.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Thanks, sbt. Once I'm done with sbt, I'll write up tests that ensure that
I haven't forgotten anything.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When I removed XXXDef(...) and XXXType(...) methods from the public API,
I put compatibility stubs in compat via implicit classes enriching
XXXExtractor traits with apply methods.
Unfortunately, this doesn't work, because if XXXDef or XXXType have
any kind of an apply method left in the public API, then implicit classes
won't even be considered when resolving calls to XXXDef(...) or XXXType(...).
Therefore I had to put those removed methods back and adorn them with an
implicit parameter that can only be resolved when "import compat._"
is in place. Quite extravagant, yes, but goes along the lines with the
design goals of the refactoring, which are:
1) Break source compatibility for users who are using methods that are
now moved to internal in order to attract attention.
2) Provide an easy way to fix the breakage by importing compat._, which
will pimp back all the missing APIs with deprecation warnings that are
going to guide migration.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Also needed for async.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
My first feeling was not to expose Symbol.flags, because that would
inevitably lead to exposing more methods on FlagSet. However we do need
flag manipulation in async, which is representative of advanced macros,
so I'm caving in.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Used by async.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Our users deserve better than this mouthful:
`appliedType(sym.asType.toTypeConstructor, List(targ1, ...))`
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
After fighting with path-dependent types to express wrappee.type,
I decided to take a different approach and replaced wrappee.type with
parametric polymorphism.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
typingTransform and typingTransform's atOwner now work both with
solitary trees and Tree+Symbol couples.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Agains, this is something that's needed for async.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Used in async when lifting definitions used in multiple states of the
async state machine. These definitions need to be lifted to class members
of the state machine.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously this was scala.reflect.internal.MissingRequirementError,
but that's not good enough for the public API.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Based on my scala/async migration experiences, I can say that having
to write `setType(tree, tpe)` instead of `tree.setType(tpe)` is a major
pain. That's why I think it makes sense to expose some functions in internal
as extension methods.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I think that the "type" suffix here is redundant, so let's rename this API
to reduce the annoyance potential.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Denys's request, renames methods in ReificationSupport that are
eponymous to methods in Universe, so that we don't get nasty name
intersections.
This change is not source/binary-compatible, because we don't make any
promises about the contents of the build API. Feedback welcome.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Before this commit, Symbol.associatedFile used to be broken in two ways.
Firstly, it was never autoloaded (just like we used to have flags,
privateWithin and annotations). Secondly, it was never filled in by runtime
reflection.
My first attempt at fixing those problems was, well, just fixing them.
However, its runtime implementation was based on a hacky function that
we were not very much excited about supported (see comments),
whereas its compile-time usefulness was somewhat questionable.
Therefore the second attempt at fixing this bug is deprecating the API
altogether, replacing it with `Symbol.pos.source`.
Since `Symbol.pos` isn't retained for runtime consumption,
`Symbol.pos.source` is still going to return `NoAbstractFile` as before
this commit, but that's left for future work, and suggested approach
is documented in SI-8259.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Seems to be useful to people, so why not expose it more widely?
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Denys’s request, this commit exposes the hack that we use to
obtain subpatterns of UnApply nodes. This is useful when writing
quasiquoting macros that do pattern matching.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Jason’s request, this commit introduces a facility to perform
tree transformations that know how to track current lexical context
and how to typecheck trees in that lexical context.
Interestingly enough, we can’t get away with the traditional “subclass the
Transformer” approach, because the required base transformer class is
declared in scala-compiler.jar, and our API is defined in scala-reflect.jar.
This forced me to play with an idea that we’ve discussed with Denys today
(actually, it’s already yesterday) - lightweight transformers that take
contextful HOFs. This commit is a sketch in that direction. Turning
`transform` and `typingTransform` into macros would make the API more
elegant (see the comments), but I didn’t have time to experiment.
I’m running short on time, so I haven’t had a chance to actually test this API,
but I’m still submitting the pull request to ignite a discussion.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Sometimes universe.internal just won’t cut it (for example, when internal
APIs need access to enclosingOwner or to the typechecker), and for that
we need c.internal.
It’s totally not a problem for us in Scala, because with first-class modules
we can just inherit c.internal from c.universe.internal and have it expose
all the basic APIs automatically. Yay for Scala!
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Jason’s and Mark’s request, this commit introduces `changeOwner`,
a facility to fixup symbol owner chains to prevent owner chain corruption
in macro expansions leading to crashes in LambdaLift and GenICode.
This is quite a low-level API that should only be used by expert users
to get their job done.
In the meanwhile we’ll be working on fixing the macro engine to
automatically prevent owner chain corruption in the first place:
https://groups.google.com/forum/#!topic/scala-internals/TtCTPlj_qcQ.
|
