| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| | |
SI-6412 some fixes for reflection leaks
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`mirrorThatLoaded(sym: Symbol): Mirror` in JavaMirrors used to iterate over
`lazy val mirrors = new WeakHashMap[ClassLoader, WeakReference[JavaMirror]]()`
to find out what mirror has loaded a certain symbol.
It worked okay until yesterday when I noticed failing tests, which crashed
when weak references in mirrors were dereferenced with get.get. Apparently
some mirrors were collected, and the logic in JavaMirror didn't account for
that possibility.
When fixing this bug, I noticed that mirrors can become unreachable even
if there are still reachable symbols created by those mirrors. That doesn't
make sense, therefore I fixed this bug as well by introducing a strong ref
from root symbols to the enclosing mirror. Therefore, any active symbol
will have a strong reference to the enclosing mirror by the virtue of the
owner chain.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Turns importer caches into fully weak hash maps, and also applies
manual cleanup to toolboxes every time they are used.
It's not enough, because reflection-mem-typecheck test is still leaking
at a rate of ~100kb per typecheck, but it's much better than it was before.
We'll fix the rest later, after 2.10.0-final.
For more information, see https://issues.scala-lang.org/browse/SI-6412 and
http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is the most blatant leak in reflection. There are others, but their impact
is much smaller, therefore we'll fix them later, after 2.10.0-final.
For more information, see https://issues.scala-lang.org/browse/SI-6412 and
http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
|
|\ \
| |/
|/| |
Changed implementation comments from /** */ to /* */ for ScalaDoc
|
| |
| |
| |
| | |
reasonable
|
|\ \
| | |
| | | |
SI-5918 fixes the ConstantType ugliness
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Java enum values are represented with constants wrapping corresponding Symbols.
To find out the underlying type of such a constant one needs to calculate
sym.owner.linkedClassOfClass.tpe (where sym represents the wrapped symbol).
To quote the source code, given (in java): class A { enum E { VAL1 } }
- sym: the symbol of the actual enumeration value (VAL1)
- .owner: the ModuleClassSymbol of the enumeration (object E)
- .linkedClassOfClass: the ClassSymbol of the enumeration (class E)
Back then, as far as I can guess, linkedClassOfClass was flaky and didn't
work well late in the compilation pipeline.
Therefore a fix to SI-1329 introduced a caching facility. Once a ConstantType
representing the type of Constant(sym) was created (I guess, during typer, when
linkedClassOfClass was still working), it cached the underlying type and used
it in subsequent phases.
***
Unfortunately this solution, being fine for enum values, broke another flavor
of constants - type wrapping constants that represent classOf (for example,
Constant(IntTpe) represents the classOf[Int] constant).
Type-wrapping constants are special, because their type (e.g. Class[Int] in the
example from the previous paragraph) changes as the compilation progresses.
Before erasure it's Class[something], and after erasure it's just Class.
Therefore caching types of such constants might lead to incorrect types
flying around after erasure, as described in this scala-internals thread:
http://groups.google.com/group/scala-internals/browse_thread/thread/45185b341aeb6a30.
***
Now when the problem is clear, the question is why didn't it happen before?
That's all because of another peculiarity of the compiler.
Before erasure package references (e.g. in TypeRef prefixes) are represented
as ThisType(sym), where sym stands for a package class symbol. After erasure
such references are represented differently, e.g. java.lang package looks like
TypeRef(TypeRef(TypeRef(NoPrefix, root, Nil), java, Nil), java.lang, Nil).
As described in the aforementioned thread, the incorrect caching strategy
employed in UniqueConstantType mixed with other caching mechanisms in compiler
effectively established a non-clearable cache that goes from Type instances to
types that represent their classOfs, e.g. from String to Class[String].
So if anyone tried to typecheck a classOf after erasure, he/she would get
Class[String] instead of the correct Class, and compiler would crash. Right?
Nope. Before erasure String is TypeRef(ThisType(java.lang), StringSymbol, Nil),
and after erasure it's TypeRef(TypeRef(...), StringSymbol, Nil), as explained
above. Therefore the foul cache would contain two String types: one pre-erasure
going to a pre-erasure Class[String], and another one post-erasure going to
a post-erasure Class.
***
This shaky balance was broken when I tried to implement class tag generation
with shiny Type.erasure method that Martin just exposed in the reflection API.
The erasure method partially invoked the Erasure phase, and for a String
it returned its post-erasure representation (with java.lang prefix represented
as TypeRef, not as ThisType). And after that I used the result of erasure
to build a classOf for a class tag. Since I did it in a macro, it was
typer, a pre-erasure phase.
Now you understand why things broke. That classOf created a Constant
wrapping a post-erasure representation of String, which cached the incorrect
non-erased Class[String] type for a post-erasure type, and things exploded.
You can imagine my panic! The ScalaDays deadline was near, I still had to do
finishing touches to implicit macros (which I actually never had time to do),
and such a fundamental thing exploded.
Actually I figured out the hashing problem, but in the limited time I had
I failed to understand why exactly it's happening, so I introduced the dirty
workaround praised in SI-5918 and moved on.
***
The story doesn't end here.
Some time has passed, and I learned a lot about the compiler. I independently
discovered the ThisType -> TypeRef transform that erasure applies to package
references and patched Type.erasure to undo it. After all, Type.erasure is a
user-facing API, and users don't need to know about post-typer implementation
details. You can read more about this here:
http://groups.google.com/group/scala-internals/browse_thread/thread/6d3277ae21b6d581
From what we've learned above, we can see that this Type.erasure fix made
the UniqueConstantType workaround unnecessary. But I didn't know that.
So imagine my surprise when I tried to remove that workaround and ran the tests
only to see that nothing fails. I went back in time to April when the problem
first manifested, extracted a minimized crasher and tried to use it on trunk.
Again, nothing crashed.
And only with the help of showRaw, I finally understood that types printed as
"String" can be wildly different. The rest was a piece of cake.
***
The irony is that the original reason for ConstantType caching is no longer
valid. linkedClassOfClass now works fine (and files/jvm/outerEnum.scala
agrees with me), so we can remove the cache altogether.
So why all this story about erasure and package references? Well, I don't know.
I enjoyed uncovering this mystery, so I wanted to share it with you :)
|
|\ \ \
| | | |
| | | | |
partest now always produces log files with LFs
|
| |/ / |
|
|\ \ \
| |/ /
|/| | |
Remove BoxingConversions from the scala package.
|
| | |
| | |
| | |
| | |
| | |
| | | |
And add it to two test cases that rely on it.
It is a remnant of the now-removed FlatArray (8cc7de74d).
|
| | |
| | |
| | |
| | |
| | |
| | | |
Now sorely needed since files with CRLF endings but
an LF attribute which are checked into the repo will
aggressively cause dirty git status on unix.
|
|\ \ \
| | | |
| | | | |
LinkedHashSet scaladoc fix after FlatHashTable->HashTable transiton
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
fix scaladoc
|
| | | | | |
|
|/ / / / |
|
|\ \ \ \ |
|
| | | | | |
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This brings all the files into line with the .gitattributes
settings, which should henceforth be automatically maintained
by git.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This should assist in keeping line endings straight.
It is designed to enforce LF endings everywhere except
for files specifically for windows.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-6394 fixes macros.Context.enclosingClass
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously I used typer.context.enclClass, but it seems to do something
completely unexpected, so I switched to manual context traversal.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fixes SI-6337 by disallowing nested value classes.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
It seems for the moment too hard to allow this, and the functionality to have value classes wrap other value classes does not seem essential.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fixes SI-5822 & SI-6305 - OSGi tests + fixes
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
* Ensure scala-library can be resolved on its own, and with sun.misc.Unsafe usage.
* Ensure reflection works without scala-compiler.jar
* Ensure ToolBox's can see all classes necessary when evaluating expressions.
* Cleanup test helper for filtering in/out bundles.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
to discover important reflection bugs in OSGi containers.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
* Adds BND manifest generation to the build.
* Adds OSGi pax-exam testing infrastructure
* Adds simple OSGi verification test for bundle resolution.
* Modifies distribution to use bundles.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
* migrates scala.tools.nsc.io portions into scala.reflect.io
* marks all classes in scala.reflect.io experimental/internal
* rewires src/reflect to use new io locations
* creates forwarders in scala.tools.nsci.io package object.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Pullreq 1342
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Position error messages about structural type members at the
problematic parameter or type.
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
As Mark's comments on SI-6336 shows, we also need to disallow value classes
as return types of structural types.
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
enable integer multiplication/divison on FiniteDuration, see SI-6389
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
- added test for “span” and “fromNow” qualifiers
- make those actually work even when there is an expected type
- add ScalaDoc to them
- verify (and fix) conversion Deadline -> FiniteDuration
- also make Int * Duration => FiniteDuration work (and test it)
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
More use of implicit classes and value classes; aliased units to
make importing TimeUnit and TimeUnit._ unnecessary; placed some
classes in their own files because "the unit of compilation is
the file" and we shouldn't bundle more than necessary; fixed some
examples.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
so that the full package can be imported naturally:
import scala.concurrent.duration._
will give you all the types (Duration, FiniteDuration, Deadline) and the
DSL for constructing these.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
- also rename divisor arguments to “divisor”
- and add a scalacheck for multiplication overflow detection
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
- without this "2.seconds * 2" will not return FiniteDuration but
Duration
- added test case verifying this behavior
- matches normal arithmetics: integers throw on div-by-zero while
doubles yield infinity; extended here to include overflow protection
on integer multiplication
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Use faster download URL now that artifactory is fixed.
|
| | |_|_|_|_|_|_|_|/
| |/| | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|/ / /
|/| | | | | | | | | |
don't try to create tags w/o scala-reflect.jar
|
| | |_|_|_|_|_|/ /
| |/| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Since recently type tags have relocated to scala-reflect.jar,
meaning that they are no longer always on library classpath.
In the compiler we do have code that generates type tags, and this code
is bound to fail if scala-reflect.jar isn't there.
I though this wouldn't be a problem, because type tag materialization
is only going to be triggered by users explicitly requesting a type tag.
That's generally true, but I overlooked a corner case. Since we provide
manifest <-> type tag compatibility, manifest lookup can sometimes trigger
tag lookup, which might result in tag synthesis, which blows up like this:
http://groups.google.com/group/scala-internals/browse_thread/thread/166ce4b71b7c46bb
This commit also ensures that type tag generation/interop doesnt sneak into the
code of the libraries that don't have scala-reflect.jar on their classpath.
For details refer to the discussion at scala-internals:
http://groups.google.com/group/scala-internals/browse_thread/thread/72f6ce3010f4d8
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
# By Martin Odersky
* pull-1352-reformatted:
Disabled failing build manager tests.
New test case for SI-6337
New test case for closing SI-6385
Value classes: eliminated half-boxing
Cleanup of OverridingPairs
Fixes SI-6260
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
When the refined build manager computes its change sets it mixes up
the types. It computes constructors of inner classes of the first
compilation that point to types of the second compilation. This
breaks a useful assertion in ExtensionMethods. The error you get for
t4245 is
java.lang.AssertionError: assertion failed: unexpected constructor
erasure A#6956.this.B#20211 for class B#6963
What goes on here is that the primary constructor of inner
class B#6963 points to the new version of that inner class
A#6956.this.B#20211. This happens during the computation of change
sets, not during normal compilation. Since it looks like the
computation of change sets is broken I have disabled the tests,
rather than disabling the assertion.
It seems that during residential compilation, the result type of a
constructor can be a different version of the enclosing class. I
could not reproduce this
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This test case shows that the variant in the comment of SI-6337 now
compiles also.
|