| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\ \ |
|
| |/ |
|
| | |
|
|\| |
|
| | |
|
| |\ \ |
|
| | |/ |
|
| | | |
|
| |/ |
|
|/
|
|
| |
late loading of nested classes in Definitions. Resolved handling of deprecated idents `then` and `macro`. Massaged test flags.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
"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.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Initially motivated by SI-5580, then just motivated. I broke up
the opaquely named JavaConversions and JavaConverters into the following
traits encapsulating some permutation of
{ to java, to scala, bidirectional }
{ wrappers, decorators }
I named everything consistently in terms of either Wrappers
or Decorators. Decorators install those asJava/asScala methods
onto collections of the right kind; Wrappers hide the process.
JavaConversions then reduces to an object which (ill-advisedly)
extends both WrapAsJava and WrapAsScala. And JavaConverters is
an object extending DecorateAsScala and DecorateAsJava. However
other more clearly named vals exist in the newly created
scala.collection.convert package object.
val decorateAsJava = new DecorateAsJava { }
val decorateAsScala = new DecorateAsScala { }
val decorateAll = new DecorateAsJava with DecorateAsScala { }
val wrapAsJava = new WrapAsJava { }
val wrapAsScala = new WrapAsScala { }
val wrapAll = new WrapAsJava with WrapAsScala { }
So for instance to import asScala decorators, and only those:
scala> import scala.collection.convert.decorateAsScala._
import scala.collection.convert.decorateAsScala._
scala> new java.util.ArrayList[String].asScala groupBy (x => x)
res0: scala.collection.immutable.Map[String,scala.collection.mutable.Buffer[String]] = Map()
I propose we put those vals or a subset of them in the scala
package object rather than way down in scala.collection.convert.
|
| | |
|
|/ |
|
|
|
|
| |
This reverts commit d8ba5d091e5641553b438ef9930a6023a2709dcd.
|
|
|
|
|
|
|
|
|
|
|
| |
Fewer deprecation warnings, prettier trees, prettier
symbols, more polished error messages.
Oh the interesting people you meet handling warnings, I
feel sorry for you all that I get to do it all the time.
One of the characters I met invited me into the "Dead Code
Society" and that's what I'm doing on Tuesdays now. No of
course you haven't, it's a SECRET society.
|
|
|
|
|
| |
Temporary reversion of irrefutability commits in interests
of stable milestone. Expect to restore shortly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The parser has always been confused about tuple patterns in
for comprehensions. It thinks it can fail to recognize an
irrefutable pattern and have it removed in refchecks, but it
is sadly mistaken, because the unnecessary filter has a tendency
to fail the compile in typer.
Look more intently for irrefutable patterns and don't insert
the unnecessary filter. Closes SI-5589, SI-1336.
|
|
|
|
|
| |
extrapolate GADT skolems: only complicate types when needed
make sure we only deskolemize GADT skolems after typedCase
|
|\ \
| | |
| | |
| | | |
'acruise/t1118', 'hubertp/issue/5572', 'hubertp/topic/nightly-checkinit', 'axel22/feature/pc-ctrie', 'jsuereth/master-version-fixin' and 'axel22/feature/checkinit-transient' into develop
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
lib/scala-compiler.jar.desired.sha1
lib/scala-library-src.jar.desired.sha1
lib/scala-library.jar.desired.sha1
src/compiler/scala/reflect/internal/Definitions.scala
src/compiler/scala/reflect/internal/Symbols.scala
src/compiler/scala/tools/nsc/Global.scala
src/compiler/scala/tools/nsc/transform/Constructors.scala
src/compiler/scala/tools/nsc/transform/Erasure.scala
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Contexts.scala
src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
src/compiler/scala/tools/nsc/typechecker/SyntheticMethods.scala
src/library/scala/Function0.scala
src/library/scala/Function1.scala
src/library/scala/Function10.scala
src/library/scala/Function11.scala
src/library/scala/Function12.scala
src/library/scala/Function13.scala
src/library/scala/Function14.scala
src/library/scala/Function15.scala
src/library/scala/Function16.scala
src/library/scala/Function17.scala
src/library/scala/Function18.scala
src/library/scala/Function19.scala
src/library/scala/Function2.scala
src/library/scala/Function20.scala
src/library/scala/Function21.scala
src/library/scala/Function22.scala
src/library/scala/Function3.scala
src/library/scala/Function4.scala
src/library/scala/Function5.scala
src/library/scala/Function6.scala
src/library/scala/Function7.scala
src/library/scala/Function8.scala
src/library/scala/Function9.scala
test/files/codelib/code.jar.desired.sha1
test/files/neg/anyval-children-2.check
test/files/run/programmatic-main.check
|
| | |
| | |
| | |
| | | |
as errors. Fixed erasure scheme.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
new STARR!
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
enforced. Super calls and specialized still missing.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
...since it works from source. The parser must be forcibly restrained
from adding a bogus constructor, but other than that it's pretty much
smooth sailing. To give an idea how smooth, if I change scala.Short like so:
trait Bippy extends Any
final class Short extends AnyVal with Bippy
Then it just works, at least until the fiction is revealed.
scala> def f(x: Bippy) = x
f: (x: Bippy)Bippy
scala> f(5)
<console>:9: error: type mismatch;
found : Int(5)
required: Bippy
f(5)
^
scala> f(5: Short)
java.lang.ClassCastException: java.lang.Short cannot be cast to scala.Bippy
at .<init>(<console>:9)
at .<clinit>(<console>)
at .<init>(<console>:11)
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
And grueling recovery from branch drift.
Merges a portion (and only a portion) of topic/inline into master.
The major changes which come with this merge are:
AnyVal is unsealed, can be extended directly.
ScalaObject is no longer with us.
|
| |\ \ \
| | |/ /
| |/| /
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
lib/scala-compiler.jar.desired.sha1
lib/scala-library-src.jar.desired.sha1
lib/scala-library.jar.desired.sha1
src/compiler/scala/reflect/internal/Definitions.scala
src/compiler/scala/reflect/internal/Importers.scala
src/compiler/scala/reflect/internal/Symbols.scala
src/compiler/scala/reflect/internal/Trees.scala
src/compiler/scala/reflect/internal/Types.scala
src/compiler/scala/tools/nsc/Global.scala
src/compiler/scala/tools/nsc/transform/Erasure.scala
src/compiler/scala/tools/nsc/transform/LiftCode.scala
src/compiler/scala/tools/nsc/transform/UnCurry.scala
src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
test/files/run/programmatic-main.check
test/files/speclib/instrumented.jar.desired.sha1
|
| | |
| | |
| | |
| | | |
And with that one, I believe all tests pass.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
-- traits can extend Any, AnyRef, or AnyVal
-- classes can extend AnyRef or AnyVal but not Any.
This breaks reflection for the moment as it smuggles AnyVal so far
downstream that it's reflecting its way into bytecode (or something)
but the following test case goes five for six as anticipated.
trait Foo1 extends Any
trait Foo2 extends AnyVal
trait Foo3 extends AnyRef
class Bar1 extends Any // fail
@inline class Bar2 extends AnyVal
class Bar3 extends AnyRef
Eliminated various hijinx from definitions.
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fail compile if AnyVal is inherited by a trait, a non-@inline
class, or a class with an AnyRef parent somewhere. Added tests.
Added logging, like
[log extmethods] Inline class class Bippy spawns extension method.
Old: def getClass: Class[_ <: Bippy]
New: final def extension$getClass($this: Bippy): Class[_ <: Bippy]
Fixed what I hope was a bug in ExtensionMethods where the original
method params were dropped.
Since adding a NonNull parent was also inflicting an AnyRef on AnyVal
subclasses, suppressed that for those. Had the bright idea that AnyVal
could extend NotNull. It doesn't seem to accomplish much, but then,
I don't think NotNull accomplishes much. Still, maybe it's time to
restrict the ways one can use AnyVal so one can't do this:
scala> var x: AnyVal = _
x: AnyVal = null
|
| | | | |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/compiler/scala/reflect/internal/Definitions.scala
|