| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
e6b4204604 moved access widenings from ExplicitOuter to
SuperAccessors to reflect them in pickled signatures so
that the inliner can take advantage of them under separate
compilation.
The followup discussion [1] determined that this wasn't
the right solution: while it enabled new separate compilation
inlinings, it failed to widen access of outer pointers and
hence prevented certain inlinings.
A better solution was proposed: modify the inliner to know
that access widening is guaranteed to have happened in
ExplicitOuter for any field accessed by an @inline-d method
body, rather than relying solely on the pickled types.
But this hasn't happened yet. In the meantime 07f94297 / #1121
reinstated the access widening to SuperAccessors, but took a
slightly different approach, using `Symbol#enclMethod` rather
than `closestEnclMethod`. That deviation triggers SI-6562.
This commit goes back to `closestEnclMethod`.
[1] https://groups.google.com/forum/#!topic/scala-internals/iPkMCygzws4
|
| |
|
|
|
|
|
| |
- Added the labels across scala.reflect and scala.reflect.macros
- Added the styling in template.css that is used by all labels
|
|\
| |
| | |
New take on SI-6534, value classes.
|
| |
| |
| |
| |
| |
| | |
Only exclude hashCode and equals from being overridden in
value classes, not other synthetics which may turn up such
as case class methods.
|
| |
| |
| |
| |
| | |
Don't prohibit equals and hashCode in universal traits;
instead, always override them in value classes.
|
|\ \
| | |
| | | |
Fixes SI-6500 by making erasure more regular.
|
| |/
| |
| |
| |
| |
| | |
With the introduction of value classes, erasure uses specialErasure where a value class C with underlying type T is unboxed to an ErasedValueType. ErasedValue types are eliminated on phase later, in post-erasure. This was done everywhere, except in the parameter types of bridge methods. That was a mistale, because that way bridge methods could not do the boxing/unboxing logic triggered by ErasedValueTypes.
Note: there is one remaining use of erasure (not specialErasure) in Erasure.scala. I put in a comment why that is OK.
|
|\ \
| | |
| | | |
SI-6578 Harden against synthetics being added more than once.
|
| |/
| |
| |
| |
| | |
Don't add synthetic methods if they already contain synthetic
methods from the set we're about to add.
|
|\ \
| | |
| | | |
Fixes SI-5031 for separate compilation scenario.
|
| |/
| |
| |
| |
| |
| |
| | |
When you have a conflicting member in package object and normal package that share the same namespace we remove the latter ClassSymbol from the scope. Now, this has an unpleasant consequence that companionClass/companionModule/companionSymbol no longer work correctly as they rely on finding the correspondent symbol using decls of the owner.
This fixes the problem of SI-5031 for separate compilation. Why the above change matters for finding foo.bar.Foo? Because when parsing the class we needed information about the static module (and we have the correct module symbol when completing the info). It's just that 043ce6d0565c9d5d960 relied on no longer valid assumptions. So we were getting NoSymbol and sym.exist was failing.
Obviously a more complete solution would be better if we didn't rely on the scope but that's too big to change for 2.10.0.
|
| |
| |
| |
| | |
In response to pull request feedback.
|
| |
| |
| |
| |
| |
| | |
It's safe to replace `localTyper.typed(atPos(pos)(tree))` with
`localTyper.typedPos(pos)(tree)` given that we're all in the
same cake and we'll get to the same `atPos`.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually this isn't needed, as partial functions can only be
defined with an expected type. But if that expected type is
and inherited method return type, the actual type of the partial
function literal is used, and the implementation detail of
`AbstractPartialFunction[A, B] with Serializable` leaks out.
After this change, the inferred types match those from
Scala 2.9.2.
ticket/6575 ~/code/scala scalac29 -Xprint:typer test/files/pos/t6575a.scala | grep def > 29.txt
ticket/6575 ~/code/scala squalac -Xprint:typer test/files/pos/t6575a.scala | grep def > 210.txt
ticket/6575 ~/code/scala diff -u 29.txt 210.txt
--- 29.txt 2012-10-28 13:51:07.000000000 +0100
+++ 210.txt 2012-10-28 13:51:20.000000000 +0100
@@ -1,7 +1,16 @@
def foo: PartialFunction[Int,Int]
def /*Y*/$init$(): Unit = {
- absoverride def foo: PartialFunction[Int,Int] = ((x0$1: Int) => x0$1 match {
+ absoverride def foo: PartialFunction[Int,Int] = {
+ def <init>(): anonymous class $anonfun = {
+ final override def applyOrElse[A1 >: Nothing <: Int, B1 >: Int <: Any](x$1: A1, default: A1 => B1): B1 = (x$1: A1 @unchecked) match {
+ final def isDefinedAt(x$1: Int): Boolean = (x$1: Int @unchecked) match {
def /*Z*/$init$(): Unit = {
- absoverride def foo: PartialFunction[Int,Int] = ((x0$2: Int) => x0$2 match {
+ absoverride def foo: PartialFunction[Int,Int] = {
+ def <init>(): anonymous class $anonfun = {
+ final override def applyOrElse[A1 >: Nothing <: Int, B1 >: Int <: Any](x$1: A1, default: A1 => B1): B1 = (x$1: A1 @unchecked) match {
+ final def isDefinedAt(x$1: Int): Boolean = (x$1: Int @unchecked) match {
def /*Comb*/$init$(): Unit = {
- absoverride def foo: PartialFunction[Int,Int] = ((x0$3: Int) => x0$3 match {
+ absoverride def foo: PartialFunction[Int,Int] = {
+ def <init>(): anonymous class $anonfun = {
+ final override def applyOrElse[A1 >: Nothing <: Int, B1 >: Int <: Any](x$1: A1, default: A1 => B1): B1 = (x$1: A1 @unchecked) match {
+ final def isDefinedAt(x$1: Int): Boolean = (x$1: Int @unchecked) match {
|
|\
| |
| | |
Disabled generation of _1, _2, etc. methods.
|
| |
| |
| |
| |
| |
| |
| | |
This was part of the introduction of ProductN, which had
to go back into pandora's box because of issues with cycles
during typing. These should have been reverted along
with it.
|
|\ \
| | |
| | | |
SI-6526 Tail call elimination should descend deeper.
|
| | |
| | |
| | |
| | |
| | | |
It wasn't traversing into Select nodes nor into the receiver of
a tail call.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
In 6eb55d4b7a we put in a remedy for an old issue SI-4560 which
had accumulated a number of sketchy partial remedies which carried
no tests to illustrate their necessity. Looks like at least one of
those was doing something useful. Here's to reversion-reversion.
This reverts commit c8bdf199, which itself reverted cb4fd6582.
|
|\ \
| | |
| | | |
Fix for SI-6537, inaccurate unchecked warning.
|
| |/
| |
| |
| |
| |
| |
| |
| | |
I found a more direct expression of the unchecked logic,
which should be much easier for others to verify. But the
bug being fixed here is that the unchecked checking happens
too early, and the sealed children of a symbol are not yet
visible if it is being simultaneously compiled.
|
|\ \
| |/
|/| |
Fixes SI-6170: issue with dragging scaladoc splitter over central iframe
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
members
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Fixed SI-6505. Respond to ask calls by immediate failure after compiler shutdown.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
shutdown.
When the compiler is asked to shutdown, it may still have items on the working queue, and more can be added by clients in other thread that don't *know* the compiler is down yet. These requests were never serviced, leading to deadlocks or timeouts.
review by @odersky, @hubertp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The instrumentation logic needed by the Scala IDE Worksheet is currently part
of the Scala project, but it doesn't need to be. I already have a PR ready for
completely removing the instrumentation logic, but I considered it too risky at
this point for 2.10.0 release (an oversight can lead to the impossibility of
running the worksheet with Scala 2.10.0).
For the moment, I believe it's better to deprecate the whole instrumentation
API in 2.10.0, and the PR for removing the instrumentation logic will target
2.10.1 or 2.11.0.
Besides deprecating the instrumentation API, this commit also raised visibility
of `interruptsEnabled` member in `Global`. This change alone is sufficient for
moving the instrumentation logic outside of the compiler, and it is needed
because the Presentation Compiler thread should never be interrupted while
instrumenting a source.
This commit is related to SI-6458
|
|\ \ \
| | | |
| | | | |
SI-6483 Prohibit super[T] references in value classes.
|
| | |/
| |/|
| | |
| | | |
This seems the safest course of action for 2.10.0.
|
| | |
| | |
| | |
| | | |
Issues a "companions must be in same file" error only if both class and module exist. This can certainly do no harm. I believe it should adress SI-6490, but, lacking a test case, I don't have evidence for that.
|
|\ \ \
| |_|/
|/| | |
Another reflection bomb
|
| | |
| | |
| | |
| | | |
We have nme.EMPTY and tpnme.EMPTY for that.
|
| | |
| | |
| | |
| | |
| | | |
And again, this is not a fatal error, so it should end with an Error,
and it should subclass not Throwable, but Exception.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Again, this is not a fatal error, so it should end with an Error,
and it should subclass not Throwable, but Exception.
Also moved the exception outside the cake to simplify error handling,
along the same lines of what've been done for parsing and reification
exceptions.
|
| | |
| | |
| | |
| | | |
Because it's not a fatal error. Neither it should subclass Throwable.
|
|\ \ \
| |_|/
|/| | |
SI-6215 Fix compiler crash on private method in value class
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes the problem with private defs in value classes by moving the $extension after the name proper rather than before. The previous scheme did not commute with makeNonPrivate:
I.e. if -ext-> is "generate extension name" and -mnp-> is "make not private" we did get for
method foo in value class Foo:
foo -ext-> extension$foo -mnp-> Foo$$extension$foo
but
foo -mnp-> Foo$$foo -ext-> extension$Foo$$foo
With the change both variations give the same name:
foo -ext-> foo$extension -mnp-> Foo$$foo$extension
but
foo -mnp-> Foo$$foo -ext-> Foo$$foo$extension
|
| |/
|/|
| |
| |
| |
| |
| |
| | |
This reopens SI-6170 that was fixed by 1be1f760. I don't want to start
a revert war, but I see two reasons we should stick to newer jquerys:
- they provide better compatibility to new browsers
- having diagrams not working is much more annoying than having the
splitter not work
|
|\ \
| | |
| | | |
AnyVal/value classes restrictions
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Nested objects, classes and lazy vals are disallowed at any
nesting level in value classes; e.g. lazy vals local to a
method defined in a value class. There are still allowed in
universal traits.
This is a temporary, implementation restriction that is planned
to be addressed in future releases of Scala. Error messages has
been updated to communicate that intent.
Moved tests for SI-5582 and SI-6408 to pending folder. They have
to stay there until implementation restrictions are addressed.
Closes SI-6408 and SI-6432.
Review by @odersky, @harrah and @adriaanm.
|
| | |
| | |
| | |
| | | |
Fixed problem reported in comment, where inner classes of value classe caused a compiler crash.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
and brought compiler in line with them. One thing we can accept IMO are nested
classes (nested objects are still a problem). In fact, it makes no sense to
exclude nested classes from value classes but not from universal traits. A class
nested in universal trait will becomes a class nested in a value class by
inheritance. Note that the reflection library already contains a universal trait
with a nested class (IndexedSeqLike), so we should accept them if we can.
|
|\ \
| |/
|/| |
SI-6436 Handle ambiguous string processors
|
| |
| |
| |
| |
| |
| |
| |
| | |
Before, we got in an inifinite loop by chasing
the error typed result of adaptToMemberWithArgs.
One point of befuddlement remains: why did t6436 and t6436b
behave differently before this change?
|