| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
Highlights the dilemma with rich type members in the cake that no longer
exists. One used to have to choose between overloading or patmat/extmeth
friendliness, but couldn't have both. Thanks to retronym we can have it all.
|
| | |\ |
|
| | |\ \ |
|
| | | | | |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Makes sure that it's possible to cover sbt's use cases, and also checks
that we can distinguish vals from vars (should anyone ever need that).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per discussion at https://groups.google.com/forum/#!topic/scala-internals/nf_ooEBn6-k,
this commit introduces the new c.enclosingOwner API that is going to serve
two purposes: 1) provide a better controlled alternative to c.enclosingTree,
2) enable low-level tinkering with owner chains without having to cast
to compiler internals.
This solution is not ideal, because: 1) symbols are much more than
I would like to expose about enclosing lexical contexts (after the
aforementioned discussion I’m no longer completely sure whether exposing
nothing is the right thing to do, but exposing symbol completers is definitely
something that should be avoided), 2) we shouldn’t have to do that
low-level stuff in the first place.
However, let’s face the facts. This change represents both an improvement
over the state of the art wrt #1 and a long-awaited capability wrt #2.
I think this pretty much warrants its place in trunk in the spirit of
gradual, evolutionary development of reflection API.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Paul’s request, this commit introduces facilities to force initialization
of reflection artifacts.
Sure, initialize (actually, even fullyInitialize) is silently performed
by Symbol.typeSignature for runtime reflection, but people don’t have to
know about that.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Jason’s additional request, this commit exposes alternatives
in the base Symbol type, rather than only in TermSymbol.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is just one of the possible strategies for compatibility with
reflection API of 2.10.x family. Here’s the discussion:
1) Do nothing.
Document the fact that we’ve organized internal APIs in a separate module
and let people figure out themselves.
Pros: no boilerplate on our side.
Cons: potential for confusion, major upfront migration effort.
2) (This commit). Introduce a compatibility pack with a manual import.
Compatibility pack lives in a separate module that has to be manually imported.
People will get compilation errors when trying to compile macros using
internal APIs against 2.11, but those will be quenched by a single
`import compat._` import. Compatibility stubs would still produce
deprecation warnings, but people can choose to ignore them to alleviate
migration costs.
Pros: brings attention of the users to the fact that they are using
internal APIs by providing a more powerful nudge than just deprecation.
Cons: even though migration effort is trivial, it is still non-zero.
3) Deprecate internal APIs in-place.
Pros: zero migration effort required.
Cons: those who ignore deprecations will be unaware about using internal APIs,
there will be some naming conflicts between Universe.xxxType and internal.xxxType
type factories.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.
In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.
This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.
This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Adds some clarifications to docs, introduces personally long-awaited
treeCopy.RefTree that lets us deal with RefTrees in a fully uniform fashion.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Presence of both decoded/encoded and decodedName/encodedName has always
baffled me, as one of those method groups is clearly redundant, and
this pull request presents a great opportunity to address this by
deprecating one of the groups.
After some deliberation, I’ve chosen decoded/encoded as the deprecation
target, because its derivation from decodedName/encodedName is easier
than the other way around.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Given that in 2.11 we have upgraded our name construction facility
from `newTxxxName` to `TxxxName`, I think it’s time we retire these
implicit conversions, as they no longer save keystrokes, but continue
to present ambient danger associated with implicit conversions.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is the first step in disentangling api#Symbol.isPackage, which is
supposed to return false for package classes, and internal#Symbol.isPackage,
which has traditionally being used as a synonym for hasPackageFlag and
hence returned true for package classes (unlike isModule which is false
for module classes).
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`Symbol.isOverride` joins `Symbol.isLocal` in the unfortunate family
of methods for which we had to break source compatibility because of
their utter brokenness.
Apparently, `isOverride` only returns true for those symbols that have
the OVERRIDE flag set (i.e. the ones that are derived from source definitions
that have the `override` modifier specified next to them). Of course,
this is very confusing, and that’s exacerbated by the fact that we can’t
fix this behavior, because there’s `internal#Symbol.isOverride` that someone
might rely on.
Given that there’s perfectly working `Symbol.allOverriddenSymbols`,
this commit removes the `Symbol.isOverride` API altogether.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Due to an unintended clash between `def getter: Symbol` (public reflection)
and `def getter(base: Symbol): Symbol` (internal reflection), the former
is uncallable from compiler internals and/or REPL’s power mode.
While both methods are guarded by compatibility constraints, we can’t
solve this problem radically and will have to live with it for some time
Thankfully, a replacement for `sym.getter` is quite approachable, namely:
`sym.getter(sym.owner)`.
In the meanwhile, I’ve deprecated the internal `getter` method by
renaming it to `getterIn`, also touching a nearby `superSymbol`. In the next
release we’ll be able to fix the name clash for good.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I have finally overcome my fear of positions and got to cleaning up its
public interface.
Apparently it isn’t so bad, since there’s a sane core of methods (thanks
to whoever wrote the comments to internal#Position):
1) Checks to distinguish offsets, opaque ranges and transparent ranges
2) Essentials that inclide start, point, end and source
3) Factories that create new positions based on existing ones
It looks like methods from the 3rd group are exactly what we’ve been looking
for in SI-6931, so we have nothing to add in this commit.
|
