| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Symbol.getFlag`, 'Symbol.hasFlag`, `Symbol.hasAllFlags`, `Symbol.annotations`
and `Symbol.privateWithin` now trigger automatic initialization of symbols
if they are used in a runtime reflection universe and some other conditions
are met (see `Symbol.needsInitialize` for details).
As the performance testing in https://github.com/scala/scala/pull/1380 shows,
this commit introduces a ~2% performance regression of compilation speed.
Unfortunately all known solutions to the bug at hand (A, B & C - all of those)
introduce perf regressions (see the pull request linked above for details).
However we're under severe time pressure, so there's no more time to explore.
Therefore I suggest this is reasonable to accept this performance hit,
because we've just gained 6% from removing scala.reflect.base,
and even before that we were well within our performance goal for 2.10.0-final.
|
| | |
|
| | |
|
| |
|
|
|
| |
The ones which remain I'm not removing on purpose, as I know
from experience it's more trouble than it's yet worth.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements SIP 16: Self-cleaning macros: http://bit.ly/wjjXTZ
Features:
* Macro defs
* Reification
* Type tags
* Manifests aliased to type tags
* Extended reflection API
* Several hundred tests
* 1111 changed files
Not yet implemented:
* Reification of refined types
* Expr.value splicing
* Named and default macro expansions
* Intricacies of interaction between macros and implicits
* Emission of debug information for macros (compliant with JSR-45)
Dedicated to Yuri Alekseyevich Gagarin
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the pursuit of simplicity and consistency.
- Method names like getType, getClass, and getValue are far too ambiguous,
both internally and especially with java reflection names. Methods which
accept or return scala symbols should not refer to them as "classes" in
the reflection library. (We can live with the FooClass convention for naming
the well-known symbols, it's names like "getClass" and "classToType" which
are needlessly conflationary.)
- Meaningless names like "subst" have to be expanded.
- We should hew closely to the terms which are used by scala programmers
wherever possible, thus using "thisType" to mean "C.this" can only beget confusion,
given that "thisType" doesn't mean "this.type" but what is normally called
the "self type."
- It's either "enclosing" or "encl", not both, and similar consistency issues.
- Eliminated getAnnotations.
- Removed what I could get away with from the API; would like to push
those which are presently justified as being "required for LiftCode" out of the core.
- Changed a number of AnyRefs to Any both on general principles and because
before long it may actually matter.
- There are !!!s scattered all over this commit, mostly where I think
the name could be better.
- I think we should standardize on method names like "vmSignature, vmClass" etc.
when we are talking about jvm (and ostensibly other vm) things.
There are a bunch more places to make this distinction clear (e.g.
Symbol's javaBinaryName, etc.)
- There is a lot more I want to do on this and I don't know where the
time will come from to do it.
Review by @odersky, @scalamacros.
|
|
|
Default getter for annotations doesn't perform initialization, hence
we've faced the following bug: https://issues.scala-lang.org/browse/SI-5423.
One of the approaches to fixing it would be to auto-complete on getter,
but according to Martin we'd better not do that because of cycles.
That's why I'm just introducing a new, eager, variation of `annotations'
and redirecting public API to it.
Review by @odersky.
|
