| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
| \ | |
|\ \| |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
|/
|
|
|
|
|
|
|
|
|
| |
This bug exists for a long time, but was triggered / discovered only lately
by the default argument of mkParams in 118aef558f.
This reverts the workaroud commit 19b6ad5ee4.
The fix is tested by test/files/presentation/memory-leaks which runs the
presentation compiler several times on Typers.scala. I could not reproduce
the memory leak in a smaller test case.
|
|
|
|
| |
More care in warning about bad comparisons.
|
| |
|
|
|
|
|
| |
And eliminating redundancy. Reduced gratuitous usage of typeConstructor
on symbols which don't have type parameters.
|
|
|
|
|
|
|
|
|
|
|
| |
Profiler said checking hasAnnotation thousands of times
is expensive. I always wondered why some things used the
SPECIALIZED flag and others looked for the annotation.
No reason emerges which is apparent from the tests. So:
- mark an annotated symbol specialized at a convenient time
- always look for the flag
- create Symbol#isSpecialized to be consistent with all others
|
|\ \ |
|
| |/ |
|
|/
|
|
|
| |
Another "three yards and a cloud of dust" in my ongoing
battle against flag uncertainty.
|
|
|
|
|
|
|
|
| |
One leads to the other.
Easing some more specific typing into Symbols.
Getting a handle on when where and how people rename
symbols to suit their fancies.
|
|\ |
|
| |
| |
| |
| | |
Also trimmed some cruft which had accrued in recent work.
|
|\ \ |
|
| |\ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
We don't use Option[Symbol].
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The example from the ticket is committed as a neg test.
The problem is that a super.m on an abstract override
member m has no concrete implementation, that is, the
trait T is not mixed in after a class C with a concrete m.
The error is noticed at phase mixin when the super accessor
is added to the concrete mixer. (Pun alert?) When super.m
is rebound, no concrete matching symbol is found up the
linearization.
Previously, it was asserted that such a symbol should
be found, but since this is our first opportunity to
detect that there is none, an error should be emitted
instead. The new message is of the form:
Member method f of mixin trait T2 is missing a concrete super implementation.
Additionally, a couple of flag tests were changed to use isAbstractOverride.
|
| |_|/
|/| |
| | |
| | | |
And test case for SI-5591.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't let OverloadedTypes reach the backend. When you want a
method from a particular symbol, avoid getMember, which may inflict
upon you an OverloadedType if an inherited member has the same
name. Instead, use the (just now appearing) definitions.getDecl.
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
Finally my dream of orderliness is within sight.
It's all pretty self-explanatory. More polymorphism, more immutable
identity, more invariants.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I just can't shake the feeling more people should see the
things that I see.
scalac -Dscalac.debug.syms foo.scala
|
|/ /
| |
| |
| | |
Don't type pattern trees with annotations still attached.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The source of many bugs over the years is that the first is
represented as a TypeRef and the second a SingleType. Over a
great period of time I figured out how to shield us from the
more obvious bug manifestations, but a recent comment by adriaan
jarred me into realizing that we can fix it at the source.
This commit changes <:< and =:= to recognize when those two
representations are being compared and to treat them as equivalent
regardless of which is on the left. The reason I don't quash one
representation entirely is that a fair bit of code depends on
singleton types having an underlying type which is not the same,
and regardless of that it would entail more changes and more risk.
The change allows removing the type inference conditions which
worried about this, and also fixes SI-4910.
scala> val t1 = typeRef(ScalaPackageClass.thisType, NoneModule.moduleClass, Nil)
t1: $r.intp.global.Type = None.type
scala> val t2 = t1.narrow
t2: $r.intp.global.Type = None.type
scala> (t1.getClass, t2.getClass)
res20: (Class[?0], Class[?0]) forSome { type ?0 <: $r.intp.global.Type; type ?0 <: $r.intp.global.Type } =
(class scala.reflect.internal.Types$ModuleTypeRef,class scala.reflect.internal.Types$UniqueSingleType)
scala> ((t1 =:= t2, t2 =:= t1, t1 <:< t2, t2 <:< t1))
res21: (Boolean, Boolean, Boolean, Boolean) = (true,true,true,true)
|
| | | |
| \ | |
|\ \ \ |
|
| | |/ |
|
|/ / |
|
|/
|
|
|
|
|
|
| |
"References to the type parameters in object-private or
object-protected values, variables, or methods (ยง5.2) of
the class are not checked for their variance position."
Review by @odersky.
|
|
|
|
|
| |
Yet more funnelling of immutable creation-time known information
into the identities of symbols and types.
|
|
|
|
|
|
|
| |
Made generic type unwrapper for use by the many methods which
need various types to be transparent with respect to the operation
being performed. AnnotatedType, PolyType, NullaryMethodType,
and ExistentialType all commonly match this description.
|
|
|
|
|
| |
More principled logic for determining if a type is a particular
type or a specialized subtype of that type.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
this corner case in Duplicators is hit when compiling
the new AbstractPartialFunction (which is specialized) under -Yvirtpatmat
TODO: why do we need to guard against cx.scope eq null in typers?
review by @vladureche
|
| |
| |
| |
| |
| |
| | |
avoid casting default call in applyOrElse:
the result type of the match is always B1,
not the result type inferred from typing the cases
|
| |
| |
| |
| |
| |
| | |
minimal fixes for typedMatchAnonFun so it compiles
TODO: support for AbstractTotalFunction (when match is exhaustive)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
runtime.AbstractPartialFunction provides a default implementation
for the new-style partial function. In principle this class is only
subclassed by compiler-generated partial functions arising from matches.
Either
- the apply method (old-style partialfun) or
- the applyOrElse method (current scheme)
must be overridden, and the isDefinedAt method implemented.
The applyOrElse method implementation is provided to ease the
transition from the old scheme, since starr still generates
old-style PartialFunctions, but locker's library has the
new AbstractPartialFunction.
Thus, this implementation is intended as a drop-in replacement for the
old partial function, and does not require changes to the compiler.
(compiler patches, both for old and new-style pattern matching, follow)
- runtime.AbstractPartialFunction is based on PartialFunction.WithDefault
Original version of FunctionWithDefault by Odersky
(http://article.gmane.org/gmane.comp.lang.scala.internals/4032)
- better performance for OrElse#applyOrElse, OrElse#lift, PF.cond
- new combinator methods: PF#run, PF#runWith, PF.apply
authored by @pavelpavlov, refactored by @adriaanm, review by @paulp
|
| |
| |
| |
| | |
A classic "off by two" error. Closes SI-4545, SI-5633.
|
|/
|
|
| |
It's -Ycheck:jvm, not -Ycheck:genjvm. There is no genjvm.
|
| |
|
|
|
|
|
|
| |
Closes SI-3569, SI-3770.
Also threw in experimental -Yoverride-vars. It's not robust.
|
|\ |
|