| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some scalac output is on stderr, and it's useful to see that
in the log file, especially for debugging.
Adds a line filter for logs, specified as "filter: pattern"
in the test source.
Backslashes are made forward only when detected as paths.
Test alignments:
Deprecations which do not pertain to the system under test
are corrected in the obvious way.
When testing deprecated API, suppress warnings by deprecating
the Test object.
Check files are updated with useful true warnings, instead of
running under -nowarn.
Language feature imports as required, instead of running under -language.
Language feature not required, such as casual use of postfix.
Heed useful warning.
Ignore broken warnings. (Rarely, -nowarn.)
Inliner warnings pop up under -optimise only, so for now, just
filter them out where they occur.
Debug output from the test required an update.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new name for AbsTypeTag was a matter of a lengthy discussion:
http://groups.google.com/group/scala-internals/browse_thread/thread/fb2007e61b505c4d
I couldn't decide until having fixed SI-6323 today, which is about
trying to reflect against a local class using typeOf.
The problem with local classes is that they aren't pickled, so their metadata
isn't preserved between Scala compilation runs. Sure, we can restore some of
that metadata with Java reflection, but you get the idea.
Before today typeOf of a local class created a free type, a synthetic symbol,
with a bunch of synthetic children that remember the metadata, effectively
creating a mini symbol table. That might be useful at time, but the problem is
that this free type cannot be reflected, because the global symbol table of
Scala reflection doesn't know about its mini symbol table.
And then it struck me. It's not the presence of abs types (type parameters and
abs type members) that differentiates arbitrary type tags from good type tags.
It's the presence of types that don't map well on the runtime world - ones that
can't be used to instantiate values, ones that can't be reflected.
So we just need a name for these types. Phantom types are compile-time only
concept, whereas our types can have partial correspondence with the runtime.
"Weak types" sound more or less okish, so let's try them out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Free symbols no longer carry signatures in their constructors.
Previously to reify a free symbol (i.e. to generate a ValDef that creates it)
one had to reify sym.info first. However reification of sym.info might lead to
unexpected side effects, including stack overflows, if reification of sym.info
recursively required reifying sym itself.
Now it's not a problem. First we reify a "header" of a free symbol
by emitting something like:
val free$Foo1 = build.newFreeTerm("Foo", Foo.this, NoFlags)`
Afterwards, when doing code generation for the reification symbol table, we
populate free symbols by inserting calls to `build.setTypeSignature($sym.info)`
This techniques transforms recursion into memoized iteration, because even if
reifying sym.info indirectly requires reification of sym itself, we remember
that we already reified sym and simply return things like Ident(free$Foo1).
2) Unfortunately I haven't been able to get rid of recursion completely.
Since some symbols (e.g. local classes) aren't pickled, we need to recreate
them during reification (this is necessary e.g. to reify RefinedTypes).
Reifier uses a special function, named `reifySymDef`, for that purpose.
Here's an example of how it works:
val symdef$_1 = build.newNestedSymbol(free$U1, newTypeName("_"),
NoPosition, DEFERRED | PARAM, false);
`reifySymDef` expands into a call to `newNestedSymbol`, which requires an owner
This essentially turns `reifySymDef` into a recursion of `reifySymDef` calls,
so that the entire owner chain get reified.
This is an implementation strategy that was employed in the first revision
of the reifier written by Martin, and personally I have no clue whether it's
really necessary to reify the parents. I leave this as a future work.
3) When working with free symbols, it's necessary to attach free symbols
to their reification. This is required in obscure nested reification scenarios,
when a symbol that was free for an inner reifee is no longer free for an outer
reifee. In that case we need to remove that free symbol from the symbol table
of the inner reification.
Back then we didn't have tree attachments, so I had to introduce a phantom
"value" parameter for `newFreeType` to keep track of the original symbols for
free types. Now when we have attachments, this is no longer necessary and
allowed me to clean up the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use Universe.showRaw instead:
scala> import scala.reflect.runtime.{universe => ru}
import scala.reflect.runtime.{universe=>ru}
scala> ru.showRaw(typeOf[Int])
res0: String = TypeRef(ThisType(scala), scala.Int, List())
scala> ru.showRaw(typeOf[Int].typeSymbol, printKinds = true)
res1: String = scala.Int#CLS
|
|
|
|
|
| |
This protects everyone from the confusion caused by stuff like this:
https://issues.scala-lang.org/browse/SI-5884
|
| |
|
|
* all usages of ClassManifest and Manifest are replaced with tags
* all manifest tests are replaced with tag tests
|