| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Adds `Type.resultType` to reflection API
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Seems to be quite an essential piece of functionality.
Got requests for it from Paul back then, and now Daniel
in his latest blog post has to painfully pattern match
his way to resultType.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TypeRef(ThisType(<package1>), sym, args) should always be equal to
TypeRef(ThisType(<package2>), sym, args) regardless of whether
package1 and package2 actually represent the same symbols of not.
This goes for subtyping (<:<) and type equality (=:=).
However regular equality (==) and hashconsing is unaffected
as per http://groups.google.com/group/scala-internals/browse_thread/thread/4bef4e6987bb68fe
This is done to account for the fact that mirrors share normal symbols,
but never share package symbols. Therefore at times it will occur that
the same types loaded by different mirrors appear different because of
the package symbols. More details: https://issues.scala-lang.org/browse/SI-5959.
|
| | |
|
| |\
| |
| | |
two pullrequests from this morning, combined to merge changes to starrs
|
| | |
| |
| |
| |
| | |
this uncovers a bug in toolboxes: https://issues.scala-lang.org/browse/SI-6007
however that bug is not critical, so it will be dealt with later
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TypeTag.String is removed because it's unclear whether it should point to
scala.Predef.String or to java.lang.String. ClassTag.String is removed to
be consistent with TypeTag.String.
This requires re-bootstrapping, because Definitions.scala in locker
expects classTag[String] being automatically generated, whereas starr
disagrees with locker on how to generate that class tag.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1) type ClassManifest[T] = ClassTag[T] (solves a problem
with toArray[T: ClassManifest] defined on most of the collections;
if these types weren't aliases, then we won't be able to change
the signature of that method to toArray[T: ClassTag], because
that would break source compatibility for those who override
toArray in their custom collections)
2) Compiler-generated manifests no longer trigger deprecation warnings
(this is implemented by using ClassManifestFactory instead of ClassManifest
and ManifestFactory instead of Manifest)
3) Deprecation messages got improved to reflect the changes
that were introduced in 2.10.0-M4.
|
| |\ \
| |/
|/| |
better module classes support in the reflection API
|
| | | |
|
| |\ \
| | |
| | | |
SI-5489 Avoid accidentally adding members to Object in erasure.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`Symbol#classBound` assumed that `refinedType` would return a
a type based on new refinement class symbol; but that isn't so
during erasure. Instead, it returns the first super class, into
which we entered new members. Needless to say, the next run of the
resident compiler didn't take kindly to these hijinks.
To remedy the situation, I've added (yet another) condition
on `phase.erasedTypes`.
|
| |/ |
|
| | |
|
| |
|
|
| |
Added compile-time option hotEnabled to Statistics that can be used to count very high frequency methods with 0 overhead for the disabled case. Fixed problem with weak maps that caused some timers to be discarded prematurely before they could be printed. Fixed problem with accouning for stacked timers.
|
| |
|
|
| |
as per https://issues.scala-lang.org/browse/SI-5951
|
| |\
| |
| | |
Statistics reorganization
|
| | |
| |
| |
| |
| | |
Statistics were broken since the move to reflect.internal. They are now
re-organized, made more robost and modular.
|
| |\ \
| |/
|/| |
improve showRaw
|
| | |
| |
| |
| | |
addresses concerns raised in http://groups.google.com/group/scala-user/browse_thread/thread/de5a5be2e083cf8e
|
| |\ \
| | |
| | | |
exposes extra tests for symbols as discussed on reflection meeting
|
| | | |
| | |
| | |
| | | |
review by @odersky
|
| |/ / |
|
| | |
| |
| |
| |
| |
| |
| | |
Wow, I wonder what the upper bound is on how long I might have chased my
tail before finding this. I know what the lower bound is, unfortunately.
It's just that usually the answer to a mystery is not "the empty package
class has magically become the root class, but only sometimes."
|
| |/ |
|
| |
|
|
|
|
| |
Compile Global or Typers twice in resident mode yielded a CyclicReference error, in phase erasure. The error was due to a cyclic call of isDerivedValue class. Checking I noted that isDerivedValue class is called very often, and mostly unneccessesarily. I tightened teh condition to not force the type of the class if it is a trait or package. This made the CyclicReference go away.
Widened criterion that enables validation of derived value classes. Previous version made two neg tests slip through.
|
| |
|
|
|
|
|
|
|
|
| |
Reduce time spent in lubs by making depth more adaptive. It now takes into account separately the depth of the lub types and the maximal depth of theior base type sequences. It cuts depth more aggressively if it is the base types instead of the types themselves that grow deep.
The old truncation behavior is retained under option -Xfull-lubs
Another change is that we now track depth more precisely, which should also help or at least allow better statistics.
Also added statistics that measure #lubs and time spent in them.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This protects everyone from the confusion caused by stuff like this:
https://issues.scala-lang.org/browse/SI-5884
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before 2.10 we had a notion of ClassManifest that could be used to retain
erasures of abstract types (type parameters, abstract type members) for
being used at runtime.
With the advent of ClassManifest (and its subtype Manifest)
it became possible to write:
def mkGenericArray[T: Manifest] = Array[T]()
When compiling array instantiation, scalac would use a ClassManifest
implicit parameter from scope (in this case, provided by a context bound)
to remember Ts that have been passed to invoke mkGenericArray and
use that information to instantiate arrays at runtime (via Java reflection).
When redesigning manifests into what is now known as type tags, we decided
to explore a notion of ArrayTags that would stand for abstract and pure array
creators. Sure, ClassManifests were perfectly fine for this job, but they did
too much - technically speaking, one doesn't necessarily need a java.lang.Class
to create an array. Depending on a platform, e.g. within JavaScript runtime,
one would want to use a different mechanism.
As tempting as this idea was, it has also proven to be problematic.
First, it created an extra abstraction inside the compiler. Along with class tags
and type tags, we had a third flavor of tags - array tags. This has threaded the
additional complexity though implicits and typers.
Second, consequently, when redesigning tags multiple times over the course of
Scala 2.10.0 development, we had to carry this extra abstraction with us, which
exacerbated the overall feeling towards array tags.
Finally, array tags didn't fit into the naming scheme we had for tags.
Both class tags and type tags sound logical, because, they are descriptors for
the things they are supposed to tag, according to their names.
However array tags are the odd ones, because they don't actually tag any arrays.
As funny as it might sound, the naming problem was the last straw
that made us do away with the array tags. Hence this commit.
|
| |
|
|
|
| |
More information can be found here:
https://groups.google.com/group/scala-internals/msg/138efc5476751269
|
| |
|
