| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was a bad interaction between anonymous subclasses
and bridge methods.
new Foo { override def bar = 5 }
Scala figures it can mark "bar" private since hey, what's
the difference. The problem is that if it was overriding a
java-defined varargs method in scala, the bridge method
logic says "Oh, it's private? Then you don't need a varargs
bridge." Hey scalac, you're the one that made me private!
You made me like this! You!
|
| |\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* 2.10.x: (37 commits)
Added logic and tests for unchecked refinements.
Moved isNonRefinementClassType somewhere logical.
Moved two tests to less breaky locations.
Nailed down the "impossible match" logic.
Finish docs for string interpolation.
moves Context.ParseError outside the cake
revives macros.Infrastructure
moves Context.runtimeUniverse to TreeBuild.mkRuntimeUniverseRef
a more precise type for Context.mirror
gets rid of macros.Infrastructure
simplifies Context.Run and Context.CompilationUnit
exposes Position.source as SourceFile
removes extraneous stuff from macros.Infrastructure
merges macros.CapturedVariables into macros.Universe
merges macros.Exprs and macros.TypeTags into Context
removes front ends from scala-reflect.jar
PositionApi => Position
hides BuildUtils from Scaladoc
MirrorOf => Mirror
docs.pre-lib now checks for mods in reflect
...
Conflicts:
test/files/neg/t4302.check
test/files/neg/unchecked.check
test/files/neg/unchecked2.check
|
| | |\ \ \
| | | | |
| | | | | |
Much better unchecked warnings.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Closes SI-6275, SI-5762.
The comment says is better than I can.
/** On pattern matcher checkability:
*
* Consider a pattern match of this form: (x: X) match { case _: P => }
*
* There are four possibilities to consider:
* [P1] X will always conform to P
* [P2] x will never conform to P
* [P3] X <: P if some runtime test is true
* [P4] X cannot be checked against P
*
* The first two cases correspond to those when there is enough static
* information to say X <: P or that !(X <: P) for all X and P.
* The fourth case includes unknown abstract types or structural
* refinements appearing within a pattern.
*
* The third case is the interesting one. We designate another type, XR,
* which is essentially the intersection of X and |P|, where |P| is
* the erasure of P. If XR <: P, then no warning is emitted.
*
* Examples of how this info is put to use:
* sealed trait A[T] ; class B[T] extends A[T]
* def f(x: B[Int]) = x match { case _: A[Int] if true => }
* def g(x: A[Int]) = x match { case _: B[Int] => }
*
* `f` requires no warning because X=B[Int], P=A[Int], and B[Int] <:< A[Int].
* `g` requires no warning because X=A[Int], P=B[Int], XR=B[Int], and B[Int] <:< B[Int].
* XR=B[Int] because a value of type A[Int] which is tested to be a B can
* only be a B[Int], due to the definition of B (B[T] extends A[T].)
*
* This is something like asSeenFrom, only rather than asking what a type looks
* like from the point of view of one of its base classes, we ask what it looks
* like from the point of view of one of its subclasses.
*/
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Scaladoc-driven cleanup for the win
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
By turning them from abstract types into full-fledged traits
implemented by our internal Run and CompilationUnit.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It was useful to pretend that SourceFile isn't a part of the API,
when it's physical location was in scala-compiler.jar.
Afterwards Position and SourceFile have been moved to scala-reflect.jar,
and (what's more important) scala-reflect.jar gained experimental status,
meaning that we're not bound by backward compatibility in 2.10.0.
Therefore I'd say we should expose a full-fledged SourceFile in Position.source
(just as we do for Symbol.associatedFile) and later find out how to strip down
its interface to something suitable for public consumption.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
libraryClassLoader can be derived from currentClassPath
currentMacro can be trivially derived from macroApplication
Backend-detection methods forXXX (as in forJVM or forScaladoc)
might be useful, but current design of this API is not future-proof.
I'm not able to come up with a better design on the spot, so
let's remove this functionality for the moment.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It was an interesting idea to give macro developers control over front ends,
but it hasn't given any visible results.
To the contrast, front ends have proven useful for toolboxes to easily control
what errors get printed where.
Therefore I'm moving front ends to scala-compiler.jar to clean up the API.
Yay for scaladoc-driven development!
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The name looks weird in the scaladoc overview panel,
so I decided to do a last-minute rename.
|
| |\| | | | |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-6412 alleviates leaks in toolboxes, attempt #2
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
In comparison with https://github.com/scala/scala/commit/b403c1d,
the original commit that implemented the fix, this one doesn't crash tests.
The problem with the original commit was that it called tryFixup() before
updating the cache, leading to stack overflows.
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | | |
And also explicitly specifies -d in a test where I forgot to do that.
Double checking never hurts.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-6277 fix for isXXX methods in reflection
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`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.
|
| | |\ \ \ \ \
| | |_|/ / /
| |/| | | | |
SI-6410 add test cases.
|
| | | | | | | |
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There were some changes to value classes since pull request
was tested so outdated check-file got merged.
Paul confirmed that those changes are going in the right
direction so all it requires is to update the check file.
Review by @paulp.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
Possible fix for SI-6344, value class generic signatures.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Value classes mostly erase to the erasure of the
underlying type. Not everything in the checkfile
looks correct, but I know from experience I can
spend the rest of my life poking at erasures, so
let's try to book some progress.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reverts commit b403c1d7524ccdfc3455b5bc5d5363fdd9c82bec.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
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 :)
|
| | |\ \ \ \ \
| | |/ / / /
| |/| | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
mkAttributedSelect, which creates a Select tree based on
a symbol, has been a major source of package object bugs,
because it has not been accurately identifying selections
on package objects. When selecting foo.bar, if foo turns
out to be a package object, the created Select tree must be
foo.`package`.bar
However mkAttributedSelect was only examining the owner of
the symbol, which means it would work if the package object
defined bar directly, but not if it inherited it.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-6381 Honour -Yrangepos in the REPL
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| / / / / /
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* 2.10.x: (36 commits)
Normalized line endings.
New .gitattributes file.
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
Use faster download URL now that artifactory is fixed.
don't try to create tags w/o scala-reflect.jar
some small remaining fixes
SI-5943 toolboxes now autoimport Predef and scala
Fix for loud test.
SI-6363 deploys the updated starr
SI-6363 removes scala.reflect.base
SI-6392 wraps non-terms before typecheck/eval
SI-6394 fixes macros.Context.enclosingClass
Error message improvement for SI-6336.
Adjustments to scala.concurrent.duration.
prepping for the refactoring
...
Conflicts:
src/actors-migration/scala/actors/Pattern.scala
src/compiler/scala/tools/nsc/Global.scala
src/compiler/scala/tools/nsc/transform/Erasure.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/library/scala/collection/immutable/Vector.scala
test/files/jvm/actmig-PinS_1.scala
test/files/jvm/actmig-PinS_2.scala
test/files/jvm/actmig-PinS_3.scala
test/files/jvm/actmig-public-methods_1.scala
|
| | |\ \ \ \ \
| | |/ / / /
| |/| | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This brings all the files into line with the .gitattributes
settings, which should henceforth be automatically maintained
by git.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
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.
|
| | |\ \ \ \ \
| | |_|/ / /
| |/| | | | |
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
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This test case shows that the variant in the comment of SI-6337 now
compiles also.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We now apply erasure of value classes everywhere. previously,
erasure was disabled in the value class itself. This led to
irregegularities and bugs. See test run/valueclasses-pavlov.scala
for something that led to a ClassCastException before.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Guards against bridge methods that clash with other methods. Two
tests: The neg test is the original ticket. The run test tweaks
things slightly so that the generated bridge method does not clash,
and tests that the necessary unboxings are indeed performed at
runtime.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-5943 toolboxes now autoimport Predef and scala
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously tb.typeCheck used default typer, which builds upon NoContext.
Changing the context to analyzer.rootContext(NoCompilationUnit, EmptyTree)
fixed the missing imports problem.
Unfortunately this doesn't help in cases like "math.sqrt(4.0)" because of
https://issues.scala-lang.org/browse/SI-6393. But anyways I'm adding
this test case to pending.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
existentially typed macro expansions now work fine
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Now, when the existential reification bug is fixed, I've been able
to take a look at SI-5418, and, apparently, the problem with importers
has fixed itself during these 9 months of the bug being active.
|
| | | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If one tries to compile the following code with the parent of this commit:
ru.reify(new Object().getClass)
then the following error will occur:
Test.scala:2: error: type mismatch;
found : $u.Expr[Class[_ <: Object]]
required: reflect.runtime.universe.Expr[Class[?0(in value <local Test>)]]
where type ?0(in value <local Test>) <: Object
ru.reify(new Object().getClass)
^
This happens because macro expansions are always typechecked against the
return type of their macro definitions instantiated in the context of expandee.
In this case the expected type contains skolems which are incompatible
with wildcards in the type of the expansion.
I tried all the incantations I could think of - without any success.
Luckily I met Martin who pointed me at the same problem solved in adapt
(see the diff w.r.t Typers.scala).
|
| | |\ \ \ \ \
| | |_|/ / /
| |/| | | | |
SI-6392 wraps non-terms before typecheck/eval
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Wrap non-term arguments of typecheck and eval, so that toolboxes
can work with full-fledged files (except for package declarations).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As the experience has shown, there's no need for a separate layer of reflection
in scala-library.jar. Therefore I'm putting an end to it.
|
