| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
NullaryMethodType was escaping. Closes SI-5099, review by moors.
|
| | |
|
| |
|
|
|
| |
Closes SI-4970, review by moors.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
| |
Suppresses ProductN parent for case classes. No review.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
at least one imminent TODO: undo hardwired generation of if/then/else,
and decide based on type whether to call flatMap/orElse or inline those
methods from Option
review by extempore
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
a type var's constraint now also tracks whether the type var was
compared to a stable type
if it was, we probably shouldn't widen the type argument that's inferred
for this var, as the result will surely fail to type check
NOTE: must be enabled using -Xexperimental
review by extempore
|
| |
|
|
|
|
|
|
|
|
|
|
| |
can't believe I missed that one...
closes SI-5033
more complete test case to make sure the multi-arglist case works as
well
no review
|
| |
|
|
|
|
|
|
|
|
| |
for now, left the old if(settings.YdepMethTpes.value) guards in comments
removed *.flags containing -Ydependent-method-types also updated one
check file with one fewer error
no review
|
| | |
|
| |
|
|
|
|
| |
I verified this creates identical library bytecode so I anticipate no
regressions. Review by prokopec anyway.
|
| |
|
|
|
| |
Reverted r25823 as it breaks specialization of traits.
|
| |
|
|
|
|
| |
Don't require a tableswitch if the matcher elected not to emit one
because there were so few cases. No review.
|
| |
|
|
|
| |
Closes SI-5071, review by prokopec.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It took me a long time to find a trivial error while adjusting the
annotation packages, so I spent even longer trying to make sure next
time it would take me less time. It's the usual business of eliminating
duplication and unnecessary indirection.
Behavioral note: there was no consistency or deducible reasoning
regarding when annotation checks would be performed against the
typeSymbol directly (thus excluding annotation subclasses) or when they
would do a subclass check. I saw no reason it shouldn't always be a
subclass check; if the annotation isn't supposed to be subclassed it
should be final, and if it is, then the subclasses had probably better
not stop exhibiting the behavior of the base class.
Example: this now draws deprecated warnings, but did not before.
class bippy extends deprecated("hi mom", "burma shave")
@bippy def f = 5
(The deprecation message isn't printed so we're not there yet, but
closer.)
There is some new internal documentation on annotations, sadly lacking
in my famous ascii diagrams, and some new conveniences. Review by rytz.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old Man Reflection is coming home and he's not going to like finding
out a bunch of beans have moved into his reflecting room. We had better
evict those guys before he blows his stack.
scala.reflect.*Bean* --> scala.beans.*
scala.beans, that's kind of a fancy package name for some beans. I
figure it's time to start fishing or cutting bait on this kind of thing.
I don't even know what beans are, but if we're going to have them in the
mainline, the least surprising place to find them is scala.beans. If we
don't want to put them in scala.beans for whatever reason, then I say
they don't belong in trunk at all.
Bonus round:
scala.annotation.target --> scala.beans.meta
I don't know if there is any more unfortunate name for a package
possible than "target". Maybe ".svn" or ".git" if you could have dots
in package names. Package CVS wouldn't hit too hard these days. Package
lib_managed? I'll try to come up with something. In any case this golden
opportunity could not be squandered.
There is a new starr included, because GenJVM contains all kinds of
shooting-from-the-hip Bean-related name hardcoding. (Yes, still. I ran
out of stones. So a few birds escape with their lives... this time.)
|
| | |
|
| |
|
|
|
| |
Fixes corner case diagnosed by miguel. Closes SI-5012, no review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
During the generation of the specialized method implementation, local
lazy vals in specialized classes were getting duplicated and assigned
new (different) names. Also, the identifiers referring to them were not
getting updated. This is fixed now. Further, the mutable flag is no
longer getting set for a lazy val during method body duplication.
Review by Dragos.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Finished giving case classes a ProductN parent, and flipped it on. The
"finish" part involved not breaking existing code where case classes
manually extend the appropriate ProductN. (Like, Tuple 1-22.)
- Generalized most of SyntheticMethods to ease method creation and class
manipulation in general.
- Fixed bugs related to the above, like the fact that this used to be a
compile error:
scala> case class Foo() extends Serializable
<console>:28: error: trait Serializable is inherited twice
case class Foo() extends Serializable
^
It feels like there's a better way to eliminate the duplicate parents,
but after spending a lot of time chasing my tail in that peril-fraught
zone between namer and typer, I don't see an easy path to improve on
it. Closes SI-1799. For that modification to Typers, review by odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added an "Abstract" method info to the specialized phase, which denotes
that no implementation should be generated.
Previously:
trait A[@specialized(Boolean) T] {
def foo: T
}
used to generate:
trait A$mcZ$sp extends A[Boolean] {
def foo$mcZ$sp = this.foo
}
which caused cyclic calls because of linearization rules when several
traits are mixed together. Now, the following is generated:
trait A$mcZ$sp extends A[Boolean] {
def foo$mcZ$sp: Boolean
}
Review by dragos.
|
| | |
|
| |
|
|
|
|
| |
Changes to Liftcode to use new reflection semantics, where a compiler
uses type checking.
|
| |
|
|
|
|
|
| |
When a reasonable lub cannot be arrived at by direct means, use the
bounds of the lub inputs to derive bounds for the lub rather than giving
up. Closes SI-4938, review by moors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes two major problems:
1. InnerClasses table missed entries
that would close the chain between
nested and top-level class.
2. In some situations, classes
corresponding to objects would be
not be reported in the InnerClasses
table.
For details it's the best to check SI-4819, SI-4820 and SI-4983.
First problem mentioned above was straightforward to fix so I won't be
going into details.
The second one deserves more attention. From now, classes corresponding
to objects are properly reported as inner classes. Also, members
(classes, objects) of objects are reported as inner classes of classes
corresponding to objects.
There's one caveat though: top level objects get two classes (regular
and mirror). Members of top-level objects are declared as inner classes
of *mirror* class and not regular one. The reason for that is to allow
importing them from Java. For example:
object A { class B }
will be compiled into following classes: A, A$, A$B. If we declared
A$B as inner class of A$ (regular class for objects) then it would be
impossible to import B using "import A.B" or "import A$.B" constructs.
The reason for that is that Java compiler seems to blindly put dollars
instead of looking at InnerClasses attribute.
Since non-top-level objects don't have a mirror class it's impossible to
use the same solution. Thus, in case like this:
object A { object B { class C } }
it's impossible to import C from Java. That's the tradeoff for fixing
other (more serious) problems. It's never been possible to do that in a
clean way so we are not making situation worse.
As a nice consequence of this change, we get better way to refer to
inner members of top-level objects. It's been reflected in one of
test-cases that is updated by this change.
Fixes SI-4789 SI-4819 SI-4820 SI-4983 and possibly some other tickets
related to reflection.
Review by extempore, dragos.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various and sundry manipulations to allow for objects to be overridden
when the mood is right. It is not enabled by default.
The major contributor of change turned out to be the decoupling of
the FINAL flag (and the "isFinal" test which examines only that flag)
and the many semantics which were attributed to this interpretation
of finality in different circumstances. Since objects no longer have
the FINAL flag automatically applied (only top-level objects and those
marked final in source code do) we need apply a more nuanced test.
Fortunately there is such a nuanced test: isEffectivelyFinal,
which is always true if the FINAL flag is set but also in various
other circumstances. In almost every case, you should be testing
"isEffectivelyFinal", not "isFinal".
To enable overridable objects, use:
-Yoverride-objects
-Xexperimental // includes the above and others
Remain to be done: working out transition logistics. Most likely this
would involve bumping the scala signature version, and all objects in
versions before that would be assumed final.
Review by moors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Made it possible to supply a custom Global to the core scala runners.
The absence of "Global pluggability", combined with the fact that most
of the functionality in Global is unnecessarily rigid due to the phases
being implemented as objects, means that it has been close to impossible
to do interesting compiler development in a way which doesn't require
modifying the scalac source tree. This then leaves you continually
subject to punishment by code drift as the various places you were
forced to modify change out from under you.
This is somewhat less true now, thanks to new option: -Yglobal-class
The primary wielders of Global (fsc/scala/scalac) now instantiate
the compiler via a (Settings, Reporter) => Global factory method in
the Global companion. If -Yglobal-class was given, that class (which
must have a (Settings, Reporter) constructor) will be instantiated if
possible, falling back on the standard one. See
test/files/pos/CustomGlobal.scala
for a working example. (It's not in run because I would have to be able
to give partest a different set of flags for successive compiles in the
same test.) Review by odersky.
|
| |
|
|
|
|
| |
Added package object support to reflection framework. Removed debug
output and made some speed improvements.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Removed and consolidated several redundant tests which had filenames
"bugXXX" and "tXXX" where XXX == XXX. No review.
|
| | |
|
| |
|
|
|
|
|
| |
Removing the code which has been deprecated since 2.8.0. Contributed by
Simon Ochsenreither, although deleting code is such fun one hesitates to
call it a contribution. Still, we will. Closes SI-4860, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reversed the values of "is" and "is not" in recent for comprehension
deprecation.
DO NOT BLOW HATCH
REPEAT
DO NOT BLOW HATCH
"Roger! Hatch blown."
Events reveal it was all baby, no bathwater. It turns out that the
specification is merely a document, not infallible holy writ as we
had all previously believed. So it is not the ABSENCE of val in a for
comprehension assignment which is deprecated, it is the PRESENCE of val.
Summarizing again, more accurately perhaps:
for (x <- 1 to 5 ; y = x) yield x+y // THAT's the one
for (val x <- 1 to 5 ; y = x) yield x+y // fail
for (val x <- 1 to 5 ; val y = x) yield x+y // fail
for (x <- 1 to 5 ; val y = x) yield x+y // deprecated
No review.
|
| |
|
|
|
|
|
| |
Fixing all the tests and source which still use the old for
comprehension syntax with vals where there are no vals and no vals where
there are vals. No review.
|
| |
|
|
|
|
|
| |
Rewrote the case class synthetic equals method to be more efficient and
to cause fewer problems for compiler hackers who are always saying stuff
like "the only place this comes up is case class equals..." No review.
|
| | |
|
| |
|
|
|
|
| |
Disabled all the old scala.reflect._ tests which are now crash-failing,
no review.
|
| |
|
|
|
|
|
|
| |
Expression type argument instantiation should not fail in a context
expecting Unit if there is any valid instantiation, because value
discarding should kick in and offer a literal (). Closes SI-4853, review
by odersky.
|
| | |
|
| |
|
|
|
| |
A few tests for pending and non-pending, no review.
|
| |
|
|
|
|
|
|
|
|
| |
Fix/workaround for inliner bug uncovered by finalizing Option methods.
Something in the backend is leaving open but empty blocks in the
worklist. Rather than freaking out at the merest mention of an empty
block, I quietly remove the empty ones. A proper fix will involve not
leaving empty blocks lying around but we're on a schedule here people.
Review by dragos.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per discussion documented in SI-1799, brought back the ProductN
traits and synthesized them into case classes. It's -Xexperimental for
now because there may be minor implications for existing code which
should be discussed. And also because I snuck in another "improvement"
but it's probably too dangerous to be touching productIterator directly
and it should go into something else.
scala> case class Bippy(x: Int, y: Int)
defined class Bippy
scala> Bippy(5, 10).productIterator
res0: Iterator[Int] = non-empty iterator
^^^----- as opposed to Iterator[Any]
There is an even better idea available than lubbing the case class field
types: it starts with "H" and ends with "List"...
Review by oderksy.
|
| |
|
|
|
|
|
|
| |
Fixed adriaan's patch for type constructor inference. The problem with
haranguing people in bars about bugs is that the fixes with which they
provide you may be flawed. Fortunately moors has this novelist on
retainer. Review by moors.
|
| |
|
|
|
|
| |
Reverting recent type constructor patch until I can see why scalacheck
is getting blinkered by it. No review.
|
