| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Unfortunately I have to revert b017629 because of SI-8303. There are projects
(e.g. slick) that use typeOf in annotations, which effectively means bye-bye.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d.
That commit lead to an error compiling Specs2:
[info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import
[info] [warn] import DiffShortener._
[info] [warn] ^
[info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion:
[info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition
[info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126)
[info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25)
[info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
|
| |\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/reflect/macros/compiler/Resolvers.scala
src/compiler/scala/reflect/macros/contexts/Typers.scala
src/compiler/scala/tools/reflect/ToolBoxFactory.scala
src/reflect/scala/reflect/api/BuildUtils.scala
|
| | |\
| | |
| | | |
SI-5920 enables default and named args in macros
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When producing an initial spec for macros two years ago, we sort of glossed
over named/default arguments in macro applications, leaving them for future work.
Once the aforementioned future has come, I’ve made several attempts at
making things operational (e.g. last summer), but it’s always been unclear
how to marry the quite complex desugaring that tryNamesDefaults performs
with the expectations of macro programmers to see unsugared trees
in macro impl parameters.
Here’s the list of problems that arise when trying to encode named/default
arguments of macro applications:
1) When inside macro impls we don’t really care about synthetic vals
that are typically introduced to preserve evaluation order in non-positional
method applications. When we inline those synthetics, we lose information
about evaluation order, which is something that we wouldn’t like to lose
in the general case.
2) More importantly, it’s also not very exciting to see invocations of
default getters that stand for unspecified default arguments. Ideally,
we would like to provide macro programmers with right-hand sides of those
default getters, but that is: a) impossible in the current implementation
of default parameters, b) would anyway bring scoping problems that we’re
not ready to deal with just yet.
Being constantly unhappy with potential solutions to the aforementioned
problems, I’ve been unable to nail this down until the last weekend,
when I realized that: 1) even though we can’t express potential twists in
evaluation order within linearly ordered macro impl params, we can use
c.macroApplication to store all the named arguments we want, 2) even though
we can’t get exactly what we want for default arguments, we can represent
them with EmptyTree’s, which is not ideal, but pretty workable. That’s
what has been put into life in this commit.
As a pleasant side-effect, now the macro engine doesn’t have to reinvent
the wheel wrt reporting errors about insufficient arg or arglist count.
Since this logic is intertwined with the tryNamesDefaults desugaring,
we previously couldn’t make use of it and had to roll our own logic
that checked that the number of arguments and parameters of macro applications
correspond to each other. Now it’s all deduplicated and consistent.
|
| | |\ \
| | | |
| | | | |
typecheck(q"class C") no longer crashes
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MemberDefs alone can't be typechecked as is, because namer only names
contents of PackageDefs, Templates and Blocks. And, if not named, a tree
can't be typed.
This commit solves this problem by wrapping typecheckees in a trivial block
and then unwrapping the result when it returns back from the typechecker.
|
| | |\ \ \
| | | | |
| | | | | |
SI-3452 Correct Java generic signatures for mixins, static forwarders
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Shares the code with the GenASM version of the fix.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The previous commit fixed this in the wrong way. The addition
to the test case (testing an inherited method from a base class
in addition to the test with a mxin method) still failed.
Like mixin, static forwarder generation uses the exact erased
siganture of the forwardee for the forwarder. It really ought
to use the as-seen-from signature (adding requisite boxing/
unboxing), but until we do that we have to avoid emitting
generic signatures that are incoherent.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Our generic signatures now match the erasure, so no
more nasty linkage errors.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[Parts of this patch and some of the commentary are from @paulp]
This took me so long to figure out I can't even tell you. Partly because
there were two different bugs, one which only arose for trait forwarders
and one for mirror class forwarders, and every time I'd make one set
of tests work another set would start failing. The runtime failures
associated with these bugs were fairly well hidden because you usually
have to go through java to encounter them: scala doesn't pay that much
attention to generic signatures, so they can be wrong and scala might still
generate correct code. But java is not so lucky.
Bug #1)
During mixin composition, classes which extend traits receive forwarders
to the implementations. An attempt was made to give these the correct
info (in method "cloneBeforeErasure") but it was prone to giving
the wrong answer, because: the key attribute which the forwarder
must capture is what the underlying method will erase to *where the
implementation is*, not how it appears to the class which contains it.
That means the signature of the forwarder must be no more precise than
the signature of the inherited implementation unless additional measures
will be taken.
This subtle difference will put on an unsubtle show for you in test
run/t3452.scala.
trait C[T]
trait Search[M] { def search(input: M): C[Int] = null }
object StringSearch extends Search[String] { }
StringSearch.search("test"); // java
// java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC;
The principled thing to do here would be to create a pair of
methods in the host class: a mixin forwarder with the erased
signature `(String)C[Int]`, and a bridge method with the same
erased signature as the trait interface facet.
But, this turns out to be pretty hard to retrofit onto the
current setup of Mixin and Erasure, mostly due to the fact
that mixin happens after erasure which has already taken
care of bridging.
For a future, release, we should try to move all bridging
after mixin, and pursue this approach. But for now, what can
we do about `LinkageError`s for Java clients?
This commit simply checks if the pre-erasure method signature
that we generate for the trait forward erases identically to
that of the interface method. If so, we can be precise. If not,
we emit the erased signature as the generic signature.
Bug #2) The same principle is at work, at a different location.
During genjvm, objects without declared companion classes
are given static forwarders in the corresponding class, e.g.
object Foo { def bar = 5 }
which creates these classes (taking minor liberties):
class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 }
class Foo { static def bar = Foo$.MODULE$.bar }
In generating these, genjvm circumvented the usual process whereby one
creates a symbol and gives it an info, preferring to target the bytecode
directly. However generic signatures are calculated from symbol info
(in this case reusing the info from the module class.) Lacking even the
attempt which was being made in mixin to "clone before erasure", we
would have runtime failures of this kind:
abstract class Foo {
type T
def f(x: T): List[T] = List()
}
object Bar extends Foo { type T = String }
Bar.f(""); // java
// java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List;
Before/after this commit:
< signature f (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>;
---
> signature f (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>;
This takes the warning count for compiling collections under
`-Ycheck:jvm` from 1521 to 26.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
SI-8266 Deprecate octal escapes in f-interpolator
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also turns the f-interpolator into a migration
assistant by suggesting alternatives for the
standard escapes.
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
SI-6908 FlatHashTable and things that depend on it can't store nulls
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixed ParFlatHashTable to use entryToElem which correctly converts sentinels to nulls.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7711 Do not emit extra argv in script body
|
| | | | |/ / / /
| | |/| | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Compiles with -Xlint to ensure there are no lurkers.
Updates `ScriptTest` to pass args to the script.
It's called `argv` partly as homage, partly because
`args` is an `Array`.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Makes sure that it's possible to cover sbt's use cases, and also checks
that we can distinguish vals from vars (should anyone ever need that).
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I think that the "type" suffix here is redundant, so let's rename this API
to reduce the annoyance potential.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As per Denys's request, renames methods in ReificationSupport that are
eponymous to methods in Universe, so that we don't get nasty name
intersections.
This change is not source/binary-compatible, because we don't make any
promises about the contents of the build API. Feedback welcome.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Before this commit, Symbol.associatedFile used to be broken in two ways.
Firstly, it was never autoloaded (just like we used to have flags,
privateWithin and annotations). Secondly, it was never filled in by runtime
reflection.
My first attempt at fixing those problems was, well, just fixing them.
However, its runtime implementation was based on a hacky function that
we were not very much excited about supported (see comments),
whereas its compile-time usefulness was somewhat questionable.
Therefore the second attempt at fixing this bug is deprecating the API
altogether, replacing it with `Symbol.pos.source`.
Since `Symbol.pos` isn't retained for runtime consumption,
`Symbol.pos.source` is still going to return `NoAbstractFile` as before
this commit, but that's left for future work, and suggested approach
is documented in SI-8259.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As per Denys’s request, this commit exposes the hack that we use to
obtain subpatterns of UnApply nodes. This is useful when writing
quasiquoting macros that do pattern matching.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As per discussion at https://groups.google.com/forum/#!topic/scala-internals/nf_ooEBn6-k,
this commit introduces the new c.enclosingOwner API that is going to serve
two purposes: 1) provide a better controlled alternative to c.enclosingTree,
2) enable low-level tinkering with owner chains without having to cast
to compiler internals.
This solution is not ideal, because: 1) symbols are much more than
I would like to expose about enclosing lexical contexts (after the
aforementioned discussion I’m no longer completely sure whether exposing
nothing is the right thing to do, but exposing symbol completers is definitely
something that should be avoided), 2) we shouldn’t have to do that
low-level stuff in the first place.
However, let’s face the facts. This change represents both an improvement
over the state of the art wrt #1 and a long-awaited capability wrt #2.
I think this pretty much warrants its place in trunk in the spirit of
gradual, evolutionary development of reflection API.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Reflection API exhibits a tension inherent to experimental things:
on the one hand we want it to grow into a beautiful and robust API,
but on the other hand we have to deal with immaturity of underlying mechanisms
by providing not very pretty solutions to enable important use cases.
In Scala 2.10, which was our first stab at reflection API, we didn't
have a systematic approach to dealing with this tension, sometimes exposing
too much of internals (e.g. Symbol.deSkolemize) and sometimes exposing
too little (e.g. there's still no facility to change owners, to do typing
transformations, etc). This resulted in certain confusion with some internal
APIs living among public ones, scaring the newcomers, and some internal APIs
only available via casting, which requires intimate knowledge of the
compiler and breaks compatibility guarantees.
This led to creation of the `internal` API module for the reflection API,
which provides advanced APIs necessary for macros that push boundaries
of the state of the art, clearly demarcating them from the more or less
straightforward rest and providing compatibility guarantees on par with
the rest of the reflection API.
This commit does break source compatibility with reflection API in 2.10,
but the next commit is going to introduce a strategy of dealing with that.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Presence of both decoded/encoded and decodedName/encodedName has always
baffled me, as one of those method groups is clearly redundant, and
this pull request presents a great opportunity to address this by
deprecating one of the groups.
After some deliberation, I’ve chosen decoded/encoded as the deprecation
target, because its derivation from decodedName/encodedName is easier
than the other way around.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Given that in 2.11 we have upgraded our name construction facility
from `newTxxxName` to `TxxxName`, I think it’s time we retire these
implicit conversions, as they no longer save keystrokes, but continue
to present ambient danger associated with implicit conversions.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This is the first step in disentangling api#Symbol.isPackage, which is
supposed to return false for package classes, and internal#Symbol.isPackage,
which has traditionally being used as a synonym for hasPackageFlag and
hence returned true for package classes (unlike isModule which is false
for module classes).
|
| |\| | | | | | |
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8188 NPE during deserialization of TrieMap
|
| | | | |/ / / /
| | |/| | | |
| | | | | | |
| | | | | | | |
The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6632 ListBuffer's updated accepts negative positions
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Changed the behavior in SeqLike.updated (which would silently accept negatives and throw on empty.tail) to throw IndexOutOfBoundException.
Updated tests to verify the behavior in ListBuffer. Everything else SeqLike will come along for the ride.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8177 specializeSym must use memberInfo on high side
|
| | | | | | | | | |
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When determining whether member `symLo` of `tpLo`
has a stronger type than member `symHi` of `tpHi`,
should we use memberType or memberInfo?
Well, memberType transforms (using `asSeenFrom`) `sym.tpe`,
whereas memberInfo performs the same transform on `sym.info`.
For term symbols, this ends up being the same thing (`sym.tpe == sym.info`).
For type symbols, however, the `.info` of an abstract type member
is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol,
so that `sym.tpe <:< sym.info`, but not the other way around.
Thus, for the strongest (correct) result,
we should use `memberType` on the low side.
On the high side, we should use the result appropriate
for the right side of the `<:<` above (`memberInfo`).
I also optimized the method a little bit by avoiding calling memberType
if the symbol on the high side isn't eligble (e.g., it's a class).
PS: I had to add a workaround to reifyType, because
we now dealias a little less eagerly, which means
a type selection on refinement class symbols makes it to reify
this broke the t8104 tests.
I also had to update the run/t6992 test, which should now test the right thing.
Tests should be commented and/or use sensible names.
What is it testing? What is the expected outcome? We should not be left guessing.
|
| | |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8153 Mutation is hard, let's go shopping with an empty list
|
| | | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Changed the implementation of iterator to be more robust to mutation of the underlying ListBuffer.
Added a test to make sure bug is gone.
Fixed an "unsafe" usage of ListBuffer.iterator in the compiler, and added a comment explaining the (new) policy for iterating over a changing ListBuffer.
The compiler now uses a synchronized-wrapped ArrayBuffer instead of ListBuffer, as that makes the (custom) units Iterator more natural to write (and avoids O(n) lookups).
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In 2fa2db7840 I fixed a bug where applicable implicit conversions
would not be found for numeric types if one introduced any aliasing
or singleton types, for the usual reasons involving the absence of
uniform type normalization. See pos/t7228 for examples - that test
case has 20 errors in 2.10.3 but compiles in master.
An unintended side effect was making implicit search less oblivious.
It turns out that in so doing I had created ambiguity where there was
none before. Not because it was any more ambiguous, but because the
compiler now had the wits to notice the ambiguity at an earlier time.
The fix for this is not intuitive. The way the internal logic is,
we need to keep the wool over implicit search's eyes, which leads
to those unrecognized types being passed to adapt, where they are
recognized and weak subtyping suffices to be more specific. It is
sufficient for SI-7228 that weak subtyping be done correctly - the
other change, which is reverted here, was exposing the type arguments
of Function1 when a view exists as a subtype of Function1.
It is also possible this could be remedied by calling weak_<:<
somewhere which is presently <:<, but I don't know where and it
has a far greater chance of affecting something else than does
this, which is a straight reversion of a post-2.10.3 change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We look for any prefix that has a refinement class for a type symbol.
This includes ThisTypes, which were not considered before.
pos/t8177g.scala, neg/t0764*scala now compile, as they should
Additional test cases contributed by Jason & Paul.
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix for SI-7475 in #3440 took care of this one.
I nixed the old (redundant) test cases and replaced by a single run/ test,
which didn't compile until.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per multiple user requests, this commit introduces a shortcut
to typecheck trees under multiple different modes: terms (EXPRmode,
was exposed in Scala 2.10) and types (TYPEmode).
Looking into the rest of a dozen of internal typechecker modes, to the
best of my knowledge, I can’t find other modes that we could expose.
FUNmode is useful, but very situational. PATTERNmode is useful, but
also situational, because we don’t expand macros inside patterns
except for whitebox extractor macros. The rest (e.g. POLYmode or TAPPmode)
are too low-level.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per https://groups.google.com/forum/#!topic/scala-internals/8v2UL-LR9yY,
annotations don’t have to be represented as AnnotationInfos and can be
reduced to plain Trees.
Due to compatibility reasons and because of the limitations of the cake
pattern used in implementing current version of Reflection, we can’t
just say `type Annotation = Tree`, however what we can definitely do is
to deprecate all the methods on Annotation and expose `tree: Tree` instead.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
While playing with tests for Type.companionType, I figured out that
companionSymbol isn’t what it seems to be:
scala> ScalaPackage.companionSymbol
res5: $r.intp.global.Symbol = <none>
scala> ScalaPackageClass.companionSymbol
res6: $r.intp.global.Symbol = package scala
Or even funnier observation:
scala> class C; object C
defined class C
defined object C
scala> val classC = typeOf[C].typeSymbol
classC: $r.intp.global.Symbol = class C
scala> val moduleC = classC.companionSymbol
moduleC: $r.intp.global.Symbol = object C
scala> classC.companionSymbol == moduleC
res0: Boolean = true
scala> moduleC.companionSymbol == classC
res1: Boolean = true
scala> moduleC.moduleClass.companionSymbol == moduleC
res2: Boolean = true
Of course, I rushed to clean this up, so that `companionSymbol` only
returns something other than NoSymbol if the target has a companion in
the common sense, not wrt the internal “class with the same name in the
same package” convention of scalac, and that `companionSymbol` for
module classes is a class, not a source module.
Unfortunately it’s not that easy, because api.Symbol#companionSymbol
has the same name as internal.Symbol#companionSymbol, so we can’t change
the behavior of the former without changing the behavior of the latter.
Therefore I deprecated api.Symbol#companionSymbol and introduced a replacement
called api.Symbol#companion with sane semantics.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Introduces a dedicated facility to go from a type to a type of its companion.
Previously we had to do something really horrible for that, something like:
tp.typeSymbol.companionSymbol.typeSignature.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
normalize is a highly overloaded name and it also conflates two distinct
operators, so how about we give our users self-explaning atomic tools instead.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per Paul’s request, this commit exposes Symbol.defString, although
in a different way to ensure consistency with our other prettyprinting
facilities provided in the reflection API.
|
