| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* commit 'refs/pull/1306/head':
SI-6356 reflection now supports Java annotations
|
| | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | | |
Except for one thingie: java enums are currently not understood
by Scala reflection, hence they aren't yet supported in annotations.
|
|\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | | |
Pullreq 1306
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Paradoxically it has less duplication but is longer.
That's the way it goes sometimes.
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | | |
Except for one thingie: java enums are currently not understood
by Scala reflection, hence they aren't yet supported in annotations.
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
deals with magic
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
First I was quite skeptical about Paul's dislike of names that contain
"magic" in them.
However when I went through the code and tried to think of "magic"-less
alternatives, it became apparent that resulting names are much better
than the originals.
Therefore I removed all the magic from reflection and macros. Feels good.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously magic classes such as NothingClass were entered twice
into root mirrors of java universes. No idea how this managed not to blow up.
Now this problem is fixed.
Also, as usual when I gain understanding of something, this allows to come up
with better names. `magicSymbols` are now split into three collections:
`magicallyEnteredClasses`, `magicallyEnteredMethods` and `magicallyHijackedSymbols`.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
cleaning up reflection
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As recent experience shows, it's hardly possible to provide a global cache
that persists between compilation runs: http://groups.google.com/group/scala-ide-user/browse_thread/thread/b1cab5588ff21f7f.
Therefore I think we need to remove Context.globalCache.
Speaking of a per-run cache, it looks like Context.cache can be
to a certain extent emulated with attachments. Otherwise, one could write
a JVM-wide static cache weakly indexed by compilation run instances
(that are available via c.currentRun).
For now I think we need to remove both caches. If macro writers really need
that functionality, we could come up with a well-thought API later.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1) parseExpr => parse
2) runExpr => eval
3) Introduces compile(Tree): () => Any, since it has frequent uses
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Internal face of AnnotationInfos is bound by backward compatibility
with compiler plugins and possibly SBT, but the public face can
be shaped in whatever fashion we like.
Hence I cleaned up the names: AnnotationInfo itself got renamed to
just Annotation, AnnotArgs got renamed to just Arguments and so on.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously Attachments allowed multiple attachments that
correspond to the same attachment type.
This created a potential for confusion, given that Attachments.get
only searched for the first attachment of a given type.
Hence I made Attachments.add overwrite previously existing attachments
of a given type and renamed it to Attachments.update, so that the name
suits the intention better.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Unfortunately we cannot remove this node, because it's emitted by typer
and, therefore, can be seen by macros and pickled as a part of annotations.
Therefore we have to expose UnApply in the API.
Experimental status of scala-reflect.jar will give us some leeway to evict it
from the compiler (and consequently from the API) by 2.10.1.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Looks like narrow doesn't help us solve the problem it was intended for:
http://groups.google.com/group/scala-user/browse_thread/thread/9f5d55ebfcc8e60a
I believe we'll be on a safer side if we remove it until it's really needed.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It's clearly redundant and also is susceptible to initialize-based bugs.
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Introduced by erasure - therefore it can be seen
neither by macros, nor by runtime reflection.
Despite never being pickled, ApplyDynamic is supported by unpickler
so I couldn't move it exclusively to scala-compiler.jar.
Figuring out the mysterious reason for pickling ApplyDynamic is left
to future work.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
A little cleanup along the Any to AnyRef trail.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Followup to 35316be and d3f879a.
- Remove obsolete comments and replace them with a test.
- Don't emit error addendum unless we know we're dealing
with a value class.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fix for SI-6245 with workaround for SI-2296.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
protected/super accessor issue: Don't subvert the creation of the
standard protected accessor with the java interop accessor. For
SI-2296, the compiler emits an error instead of causing an illegal
access error at runtime.
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
Topic/empty array optimization
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
There's that empty array. When compiling "trait Foo", this
took me from allocating 44,410 empty arrays to allocating
383 of them.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Because there are lots of times when you just need an
array and shouldn't have to allocate one every time or
pick a random spot to cache yet another empty array.
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
Eliminate breaking relative names in source.
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
These things are killing me. Constructions like
package scala.foo.bar.baz
import foo.Other
DO NOT WORK in general. Such files are not really in the
"scala" package, because it is not declared
package scala
package foo.bar.baz
And there is a second problem: using a relative path name means
compilation will fail in the presence of a directory of the same
name, e.g.
% mkdir reflect
% scalac src/reflect/scala/reflect/internal/util/Position.scala
src/reflect/scala/reflect/internal/util/Position.scala:9: error:
object ClassTag is not a member of package reflect
import reflect.ClassTag
^
src/reflect/scala/reflect/internal/util/Position.scala:10: error:
object base is not a member of package reflect
import reflect.base.Attachments
^
As a rule, do not use relative package paths unless you have
explicitly imported the path to which you think you are relative.
Better yet, don't use them at all. Unfortunately they mostly work
because scala variously thinks everything scala.* is in the scala
package and/or because you usually aren't bootstrapping and it
falls through to an existing version of the class already on the
classpath.
Making the paths explicit is not a complete solution -
in particular, we remain enormously vulnerable to any directory
or package called "scala" which isn't ours - but it greatly
limts the severity of the problem.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Two pull requests crossed in the night.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-6331 deconst If type / refine equality of floating point Constant types.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
- Incorporate `tag`, which is considered by equals, to reduce collisions.
- Use the result of floatToRawIntBits(value) / doubleToRawLongBits(value),
rather than value. This wasn't strictly necessary as (0d.## == (-0d).##)
but this is more obviously correct.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
For the examples I've constructed, they are consistent, but
I put this down to good luck, rather than good management.
The next commit will address this.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The constant types for 0d and -0d should not be equal.
This is implemented by checking equality of the result of
doubleToRawLongBits / floatToRawIntBits, which also correctly
considers two NaNs of the same flavour to be equal.
Followup to SI-6331.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The fast path in typedIf added in 8552740b avoided lubbing the if/else branch types
if they are identical, but this fails to deconst the type. This could lead to the entire
if expression being replaced by a constant.
Also introduces a new tool in partest for nicer checkfiles.
// in Test.scala
trace(if (t) -0d else 0d)
// in Test.check
trace> if (Test.this.t)
-0.0
else
0.0
res: Double = -0.0
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Made 'def clone()' consistent with parens everywhere.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
For the reference of others,
ack --files-with-matches 'def clone[:\s]' src
is how you might find out who needs fixing.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Fix SI-4813 - Clone doesn't work on LinkedList.
|
| | |_|/ / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
* Added extensive test for clone across all standard mutable collections
* Fixed clone implementations when needed so they work.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
improvements for type tags
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Updates the starr with the changes introduced by the previous commit.
Cleans up obsolete symbols required by the previous starr.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Free types are no longer acceptable in normal type tags.
Like type parameters or abstract type members they don't map on any real type,
therefore I think this is a justified change.
The main reason for doing is this is to prohibit people from using `typeOf`
on local classes. Sure, the guard introduced in the previous commit will raise
runtime errors about that, but this commit provides static checking.
Those especially persistent might use `absTypeOf` and then try to play around
with the weak type it returns, but that's advanced usage scenario, and I don't
worry much about it.
Bottom line: `typeOf` should just work.
Things that work with additional effort should be explicitly marked as such.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
One of the use cases for free types is reification of local classes.
The result is very seamless. Despite that local classes are not pickled,
free types recreated the symbols referenced by local classes, so that we
get our own symbol table, which can be analyzed with usual precision of
pickled symbols and types.
However when we try to use those symbols for reflection, we hit a problem.
Scala runtime reflection uses its own mechanism for dealing with non-pickled
types, which is incompatible with mini symbol tables used in free types.
Therefore to prevent confusion, I prohibit using those symbols for reflection.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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.
|
| | |/ / / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
build.newFreeType does exactly the same, so we don't have a need
in two different methods. Type parameters and existentially bound syms
can later be distinguished using flags.
|
|\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | | |
Fix for SI-6340, error message regression.
|
| | |_|/ / / /
| |/| | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6359 Deep prohibition of templates in value class
|
| |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | | |
This seems to have been the intent of 95d532 / SI-5882.
|
|\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | | |
Fixes SI-6259. Unable to use typeOf in super call of top-level object.
|
|/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This works around the issue of the inability to use classOf for top-level object classes by inventing a new
anonymous class and instantiating it just to grab its class. Since the class is a nested type of the
top-level object it'll be in the same classloader unless some kind of evil behavior is afoot.
This patch should be undone if ever SI-2453 ever gets fixed, or we wind up with a direct way to grab
the class of an object.
|