| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Miscellania:
Miscellania is a small island off the northernmost part
of the Fremennik Isles - RunScape Wiki
Miscellanea:
A collection of miscellaneous objects or writings - Merriam-Webster
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specialization creates a subclasses of a specializd class for each
type parameter combination. These contains copies of the methods from
the superclass.
However, before this transform, the pattern of self-synchronization
in a method body had been replace by flag Flag.SYNCHRONIZED on the
method symbol. This was not being propagated to the override, and
hence no locking occured.
This commit modifies the creation of the specialized overload symbol
to copy the SYNCHRONIZED flag, as was already done for ASBOVERRIDE.
I have also done the same for the `@strictfp` annotation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Essentially, we fuse mixin and lazyvals into the fields phase.
With fields mixing in trait members into subclasses, we
have all info needed to compute bitmaps, and thus we can
synthesize the synchronisation logic as well.
By doing this before erasure we get better signatures,
and before specialized means specialized lazy vals work now.
Mixins is now almost reduced to its essence: implementing
super accessors and forwarders. It still synthesizes
accessors for param accessors and early init trait vals.
Concretely, trait lazy vals are mixed into subclasses
with the needed synchronization logic in place, as do
lazy vals in classes and methods. Similarly, modules
are initialized using double checked locking.
Since the code to initialize a module is short,
we do not emit compute methods for modules (anymore).
For simplicity, local lazy vals do not get a compute method either.
The strange corner case of constant-typed final lazy vals
is resolved in favor of laziness, by no longer assigning
a constant type to a lazy val (see widenIfNecessary in namers).
If you explicitly ask for something lazy, you get laziness;
with the constant-typedness implicit, it yields to the
conflicting `lazy` modifier because it is explicit.
Co-Authored-By: Lukas Rytz <lukas@lightbend.com>
Fixes scala/scala-dev#133
Inspired by dotc, desugar a local `lazy val x = rhs` into
```
val x$lzy = new scala.runtime.LazyInt()
def x(): Int = {
x$lzy.synchronized {
if (!x$lzy.initialized) {
x$lzy.initialized = true
x$lzy.value = rhs
}
x$lzy.value
}
}
```
Note that the 2.11 decoding (into a local variable and a bitmap) also
creates boxes for local lazy vals, in fact two for each lazy val:
```
def f = {
lazy val x = 0
x
}
```
desugars to
```
public int f() {
IntRef x$lzy = IntRef.zero();
VolatileByteRef bitmap$0 = VolatileByteRef.create((byte)0);
return this.x$1(x$lzy, bitmap$0);
}
private final int x$lzycompute$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
C c = this;
synchronized (c) {
if ((byte)(bitmap$0$1.elem & 1) == 0) {
x$lzy$1.elem = 0;
bitmap$0$1.elem = (byte)(bitmap$0$1.elem | 1);
}
return x$lzy$1.elem;
}
}
private final int x$1(IntRef x$lzy$1, VolatileByteRef bitmap$0$1) {
return (byte)(bitmap$0$1.elem & 1) == 0 ?
this.x$lzycompute$1(x$lzy$1, bitmap$0$1) : x$lzy$1.elem;
}
```
An additional problem with the above encoding is that the `lzycompute`
method synchronizes on `this`. In connection with the new lambda
encoding that no longer generates anonymous classes, captured lazy vals
no longer synchronize on the lambda object.
The new encoding solves this problem (scala/scala-dev#133)
by synchronizing on the lazy holder.
Currently, we don't exploit the fact that the initialized field
is `@volatile`, because it's not clear the performance is needed
for local lazy vals (as they are not contended, and as soon as
the VM warms up, biased locking should deal with that)
Note, be very very careful when moving to double-checked locking,
as this needs a different variation than the one we use for
class-member lazy vals. A read of a volatile field of a class
does not necessarily impart any knowledge about a "subsequent" read
of another non-volatile field of the same object. A pair of
volatile reads and write can be used to implement a lock, but it's
not clear if the complexity is worth an unproven performance gain.
(Once the performance gain is proven, let's change the encoding.)
- don't explicitly init bitmap in bytecode
- must apply method to () explicitly after uncurry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There isn't much point to the late* flags in a world where
we're mutating flags left and right in tree and info transformers...
So, lets get rid of the indirection until we can include flags
in a symbol's type history, like we do for its info.
This retires lateDEFERRED (redundant with SYNTHESIZE_IMPL_IN_SUBCLASS).
Since it's introduced so late, it makes little sense to have these
synthetic members go back to DEFERRED. Instead, just set DEFERRED directly.
Also remove unused late* and not* flags.
notPRIVATE subsumes lateFINAL for effective finality (scala/scala-dev#126)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The body of lambdas is compiled into a synthetic method
in the enclosing class. Previously, this method was a public
virtual method named `fully$qualified$Class$$anonfun$n`.
For lambdas that didn't capture a `this` reference, a static
method was used.
This commit changes two aspects.
Firstly, all lambda impl methods are now emitted static.
An extra parameter is added to those that require a this
reference.
This is an improvement as it:
- allows, shorter, more readable names for the lambda impl method
- avoids pollution of the vtable of the class. Note that javac uses
private instance methods, rather than public static methods. If
we followed its lead, we would be unable to support important use
cases in our inliner
Secondly, the name of the enclosing method has been included in
the name of the lambda impl method to improve debuggability and
to improve serialization compatibility. The serialization improvement
comes from the way that fresh names for the impl methods are
allocated: adding or removing lambdas in methods not named "foo" won't
change the numbering of the `anonfun$foo$n` impl methods from methods
named "foo". This is in line with user expectations about anonymous
class and lambda serialization stability. Brian Goetz has described
this tricky area well in:
http://cr.openjdk.java.net/~briangoetz/eg-attachments/lambda-serialization.html
This commit doesn't go as far a Javac, we don't use the hash of the
lambda type info, param names, etc to map to a lambda impl method name.
As such, we are more prone to the type-1 and -2 failures described there.
However, our Scala 2.11.8 has similar characteristics, so we aren't going
backwards.
Special case in the naming: Use "new" rather than "<init>" for constructor enclosed
lambdas, as javac does.
I have also changed the way that "delambdafy target" methods are identifed.
Rather than relying on the naming convention, I have switched to using a
symbol attachment. The assumption is that we only need to identify them
from within the same compilation unit.
This means we can distinguish impl metbods for expanded functions
(ones called from an `apply` method of an ahead-of-time expanded
anonfun class), from those that truly end up as targets for lambda
metafactory. Only the latter are translated to static methods in
this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Erasure first replaces null.asInstanceOf[Int] by unbox(null). If the
expected type erases to object, erasure then introduces a box operation,
yielding box(unbox(null)). Note that this value is a box of zero, not
null.
Erasure has an optimization to replace box(unbox(x)) in case x is
of primitive type. 60f1b4b extended this to the case when x is null,
which is incorrect in general. The reason was to prevent creating a
primitive box to be stored in the unused generic field when creating
an instance of a specialized class. A special case ensures that this
optimization is still performed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a SAM type is specialized (i.e., a specialized type
parameter receives a specialized type argument), do not use
LambdaMetaFactory (expand during Uncurry instead).
This is an implementation restriction -- the current
specialization scheme is not amenable to using
LambdaMetaFactory to spin up subclasses. Since the generic
method is abstract, and the specialized ones are concrete,
specialization is rendered moot because we cannot implement
the specialized method with the lambda using LMF.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The term "specialized override" is used to describe a method
in a synthetic specialized subclass that generically substitutes
the specialized type args into the siganture of a generic method.
For example, `trait T[@spec A] { def t(a: A) }` gives rise to
`def t(a: Int)` under the type environment `A=Int`.
This commit avoids doing this for specialized traits, only classes
have these overrides now. The motivation is to make it simpler to
use specialized interfaces (like `T$mcI$sp` from the example above)
as Java functional interfaces.
|
|\
| |
| | |
Use LambdaMetafactory where possible for lambda creation.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
```
scala> (x: Int) => {??? : Int}
res2: Int => Int = $$Lambda$1371/1961176822@6ed3ccb2
scala> res2(42)
scala.NotImplementedError: an implementation is missing
at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225)
at .$anonfun$1(<console>:8)
at $$Lambda$1371/1961176822.apply$mcII$sp(Unknown Source)
... 33 elided
scala> (x: Int, y: Long) => {??? : Int}
res4: (Int, Long) => Int = $$Lambda$1382/1796047085@6f8e8894
scala> res4(0, 0L)
scala.NotImplementedError: an implementation is missing
at scala.Predef$.$qmark$qmark$qmark(Predef.scala:225)
at .$anonfun$1(<console>:8)
at $$Lambda$1382/1796047085.apply$mcIIJ$sp(Unknown Source)
... 33 elided
```
|
|/
|
|
|
| |
This commit corrects many typos found in scaladocs and comments.
There's also fixed the name of a private method in ICodeCheckers.
|
|
|
|
| |
... replaced by hasPackageFlag, hasSymbolIn, getterIn, setterIn.
|
|\
| |
| | |
SI-9089 Another REPL/FSC + specialization bug fix
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The enclosed test case stopped working in 2.11.5 on the back of
https://github.com/scala/scala/pull/4040.
The key change was that we ran all post-typer info transformers
on each run of the compiler, rather than trying to reuse the results
of the previous run.
In that patch, I noticed one place [1] in specialization that
aggressively entered specialized members into the owning scope,
rather than relying on `transformInfo` to place the new members
in the scope of the newly created element of the info history.
I made that change after noticing that this code could actually
mutated scopes of specializaed types at the parser phase, which
led to fairly obscure failures.
This bug is another one of these obscure failures, and has the
same root cause. We effectively "double specialiaze" Function0,
which trips an assertion when `method apply$mcI$sp` is found
twice in a scope.
I have found another spot that was directly manipulating the scope,
and removed the offending code.
[1] https://github.com/scala/scala/pull/4040#commitcomment-8531516
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
|
|
|
|
|
| |
08505bd added a workaround for an undiagnosed interaction
between resident compilation and specialzation. This is no
longer needed after the previous commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The transformation of applications to specialized methods
relies on the owner of said method having had the specialization
info transform run which stashes a bunch of related data into
per-run caches such as `SpecializeTypes#{typeEnv}`.
Recently, we found that per-run caches didn't quite live up
to there name, and in fact weren't being cleaned up before
a new run. This was remedied in 00e11ff.
However, no good deed goes unpunished, and this led to a
regression in specialization in the REPL and FSC.
This commit makes two changes:
- change the specialization info tranformer to no longer
directly enter specialized methods into the `info` of whatever
the current phase happens to be. This stops them showing up
`enteringTyper` of the following run.
- change `adaptInfos` to simply discard all but the oldest
entry in the type history when bringing a symbol from one
run into the next. This generalizes the approach taken to
fix SI-7801. The specialization info transformer will now
execute in each run, and repopulate `typeEnv` and friends.
I see that we have a seemingly related bandaid for this sort
of problem since 08505bd4ec. In a followup, I'll try to revert
that.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test case demonstrates that this is important for serialization
and for strictfp. (Although the latter is still pretty broken,
see SI-7954.)
Now that the synthetic subclass of `Tuple2[Int, Int]` also has the
`@deprecatedInheritance` annotation, I had to change the spot that
issues this warning to be silent after the typer phase. Otherwise,
we get two warnings in `run/t3888.scala`. This also remedies double
warnings that were incurred in `neg/t6162-inheritance`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I removed XXXDef(...) and XXXType(...) methods from the public API,
I put compatibility stubs in compat via implicit classes enriching
XXXExtractor traits with apply methods.
Unfortunately, this doesn't work, because if XXXDef or XXXType have
any kind of an apply method left in the public API, then implicit classes
won't even be considered when resolving calls to XXXDef(...) or XXXType(...).
Therefore I had to put those removed methods back and adorn them with an
implicit parameter that can only be resolved when "import compat._"
is in place. Quite extravagant, yes, but goes along the lines with the
design goals of the refactoring, which are:
1) Break source compatibility for users who are using methods that are
now moved to internal in order to attract attention.
2) Provide an easy way to fix the breakage by importing compat._, which
will pimp back all the missing APIs with deprecation warnings that are
going to guide migration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There’s been a conflation of two distinct meanings of the word “local”
in the internal symbol API: the first meaning being “local to this”
(as in has the LOCAL flag set), the second meaning being “local to block”
(as in declared in a block, i.e. having owner being a term symbol).
Especially confusing is the fact that sym.isLocal isn’t the same as
sym.hasFlag(LOCAL), which has led to now fixed SI-6733.
This commit fixes the semantic mess by deprecating both Symbol.isLocal and
Symbol.hasLocalFlag (that we were forced to use, because Symbol.isLocal
had already been taken), and replacing them with Symbol.isLocalToThis
and Symbol.isLocalToBlock. Unfortunately, we can’t remove the deprecated
methods right away, because they are used in SBT, so I had to take small
steps.
|
|\
| |
| | |
Avoid generic collections operations hot paths
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Use a specialized version of List#{map, collectFirst}
These special case mapping over an empty list and avoid
allocating.
- Avoid nonEmpty in favor of `ne Nil`
I see in the order of 2% speedup.
Perhaps more useful is that
these methods no longer dominate the YourKit profiles, even though
profiler bias due to safepoints at allocation of the ListBuffer
might have been overstating their significance.
|
|\ \
| |/
|/| |
SI-7700 @unspecialized, Part Deux: Now Working.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This annotation was introduced to allow us to mark methods within
a specialized trait as immune from specialization. In particular,
this is desirable for `Function1.{andThen, compose}`.
However, it seems we need to check for this in two places in the
specialization code base. The feature is now backed with a test.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This experimental option typechecked arguments of annotations
with an injected value in scope named `self`:
@Foo(self.foo < 1)
This has been slated for removal [1] for some time.
This commit removes it in one fell swoop, without any attempt
at source compatibility with code that constructs or pattern
matches on AnnotatedType.
[1] https://groups.google.com/d/msg/scala-internals/VdZ5UJwQFGI/C6tZ493Yxx4J
|
|
|
|
|
|
|
| |
This reverts a tiny bit of f7d5f45aa7 where the crasher was
introduced. The enclosed test case compiles and runs under 2.9,
but prints the wrong answer. It crashes in 2.10 and until this
patch. Now it compiles and prints the right answer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.
This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.
In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.
The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.
The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.
|
|
|
|
|
|
|
|
| |
During development of late delmabdafying there was a problem where
specialization would undo some of the work done in uncurry if the body
of the lambda had a constant type. That would result in a compiler crash
as when the delambdafy phase got a tree shape it didn't understand.
This commit has a fix and a test.
|
|
|
|
|
| |
Looks like emptyValDef.isEmpty was already changed to return
false, so now all that's left is a name which means something.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TreeDSL has no future - it was always a temporary measure
waiting for something like quasiquotes to come along. In this
commit I cull as much of it as I can, especially the delicate
matter of creating new DefDefs and ValDefs, which I completely
turn over to the old style creators.
I unified all the symbol-based DefDef and ValDef creators under
a single method, since it was yet another place where ctrl-C and
ctrl-V were being punched with glee. Was beaten to the punch on
adding copyTypeDef to fill out the *Def creators.
Eliminated as many redundant positioning calls as I could find.
If you are creating a DefTree tree based on a symbol, it will
always have an atPos(sym.pos) { ... } wrapped around it. You
don't need another one.
All of this is motivated by positions work: positions are
assigned in so many places and in such an ad hoc fashion that
it is impossible to bring consistency to that without first
bringing some consistency to tree creation.
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Duplicators.scala
src/library/scala/concurrent/Future.scala
test/files/jvm/scala-concurrent-tck.scala
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Specialization rewires class parents during info transformation, and
the new info then guides the tree changes. But if a symbol is created
during duplication, which runs after specialization, its info is not
visited and thus the corresponding tree is not specialized.
One manifestation is the following:
```
object Test {
class Parent[@specialized(Int) T]
def spec_method[@specialized(Int) T](t: T, expectedXSuper: String) = {
class X extends Parent[T]()
// even in the specialized variant, the local X class
// doesn't extend Parent$mcI$sp, since its symbol has
// been created after specialization and was not seen
// by specialzation's info transformer.
...
}
}
```
We can fix this by forcing duplication to take place before specialization.
Review by @dragos, @paulp or @axel22.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This performs method specialization inside a scope other than a {class,
trait, object}: could be another method or a value. This specialization
is much simpler, since there is no need to record the new members in
the class signature, their signatures are only visible locally.
It works according to the usual logic:
- we use normalizeMember to create the specialized symbols
- we leave DefDef stubs in the tree that are later filled in by tree
duplication and adaptation
The solution is limited by SI-7579: since the duplicator loses the sym
annotations when duplicating, this expansion and rewiring can only take
place in code that has not been subject to duplication. You can see the
test case for an example.
Review by @dragos, @paulp or @axel22.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a continuation of 1591c14e50, which didn't go far enough
to handle method calls with a mix of specialized and unspecialized
type parameters.
This commit modifies `specSym` to calculate the residual type
of the original method after specialized type parameters have
been removed and the type environment of the candidate specialized
variant has been subsituted.
For example, here is trace of `specSym` when searcing for the
specialized variant of `f4` in the enclosed test:
tree = Main.this.f4[Nothing, Int]
tree.tpe = (a: Int, b: List[(Int, Nothing)])String
fun.tpe = [B, A](a: A, b: List[(A, B)])String
residualTreeType = [B](a: Int, b: List[(Int, B)])String
memberType = [B](a: Int, b: List[(Int, B)])String
env = Map(type A -> Int)
doesConform = true
A few "todo" tests are included that highlight an endemic
issue with the current specialization implementation: type
parameters that show up after `uncurry` might be clones of
the original symbols from typer, if they have been through
a TypeMap (e.g. within a call to `uncurryTreeType`). So testing
them for existence with the `typeEnv` map is fruitless.
No amount of `atPhase` acrobatics can rescue us from this;
we need to transport this information in a symbol-cloning
resiliant manner. Maybe Symbol Attachments?
|
| |
| |
| |
| | |
As noted by reviewer.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have lots of core classes for which we need not go through
the symbol to get the type:
ObjectClass.tpe -> ObjectTpe
AnyClass.tpe -> AnyTpe
I updated everything to use the concise/direct version,
and eliminated a bunch of noise where places were calling
typeConstructor, erasedTypeRef, and other different-seeming methods
only to always wind up with the same type they would have received
from sym.tpe. There's only one Object type, before or after erasure,
with or without type arguments.
Calls to typeConstructor were especially damaging because (see
previous commit) it had a tendency to cache a different type than
the type one would find via other means. The two types would
compare =:=, but possibly not == and definitely not eq. (I still
don't understand what == is expected to do with types.)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:
package scala.collection.mutable
Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:
// a.scala
package scala.foo
class Bar { new util.Random }
% scalac ./a.scala
% mkdir util
% scalac ./a.scala
./a.scala:4: error: type Random is not a member of package util
new util.Random
^
one error found
There are two ways to play defense against this:
- don't use relative paths; okay sometimes, less so others
- don't "opt out" of the scala package
This commit mostly pursues the latter, with occasional doses
of the former.
I created a scratch directory containing these empty directories:
actors annotation ant api asm beans cmd collection compat
concurrent control convert docutil dtd duration event factory
forkjoin generic hashing immutable impl include internal io
logging macros man1 matching math meta model mutable nsc parallel
parsing partest persistent process pull ref reflect reify remote
runtime scalap scheduler script swing sys text threadpool tools
transform unchecked util xml
I stopped when I could compile the main src directories
even with all those empties on my classpath.
|
|\ \
| | |
| | | |
Change unrecognized scaladoc comments to C-style
|
| | | |
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
merge/v2.10.1-245-g5147bb2-to-master
Conflicts:
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
| |\ \
| | | |
| | | | |
SI-7329 duplicate default getters for specialized parameters.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The default getter is generated with @specialized annotation if the
type parameter corresponding to the type of the parameter is
specialized. Consequently specialize pass tries to generate overloads.
Rather than pruning overloads to exclude duplicates, let's notice
that default getter specialization is not needed at all:
- The dynamic scope of default getter doesn't include specialized
method or class constructor.
- generic default getter is called even when calling specialized
method:
object V {
@specialized def foo[@specialized B](b: B = (??? : B)) = {}
foo[Int]()
}
gives:
invokevirtual Method V$.foo$default$1:()Ljava/lang/Object;
invokestatic (unboxToInt)
invokevirtual Method V$.foo$mIc$sp:(I)V
|
|\| | |
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
merge/v2.10.1-235-g4525e92-to-master
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/reflect/scala/reflect/internal/Types.scala
|
| |/
| |
| |
| |
| |
| | |
Specialize assigns SpecialOverride info to a specialized method
even when there is a further specialization that should be forwarded
to.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* origin/2.10.x:
if starr.use.released fetch Scala ${starr.version} for STARR
assume build.release when maven.version.suffix is set
make quick.done depend on quick.bin again
SI-7321 Memory leak in specialize on multiple compiler runs.
Take the N^2 out of the compiler's TreeSet.
SI-6900 Fix tailrec for dependent method types
Simplify interplay between Uncurry Info- and Tree-Transformers
Refactor existential related code out of types.
Add a cautionary comment to TreeSymSubstitutor.
SI-6715 Shouldn't return "" from TermNames.originalName
Backport #2289's TermNames.unexpandedName as TermNames.originalName
SI-7147 Diagnostic for unexplained assertion in presentation compiler.
SI-6793 Don't use super param accessors if inaccessible.
Correct sorting example for Ordering in scaladoc
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
build.xml
src/compiler/scala/tools/nsc/transform/UnCurry.scala
src/reflect/scala/reflect/internal/StdNames.scala
|
| |
| |
| |
| |
| |
| |
| |
| | |
Currently the map is declared LinkedHashMap, which doesn't align with
other caching maps that are cleared on every run. Linkedness is only
needed to ensure deterministic order on the generated specialized
classes. The same can be accomplished by sorting generated classes
a-posteriori.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Squashed commit of the following:
commit a3680be29ccd5314c5d027d473b37940eaecd530
Author: Paul Phillips <paulp@improving.org>
Date: Fri Aug 31 10:20:16 2012 -0700
Actual fix for SI-6301, specialized crasher.
This means the workaround in the previous commit is no
longer reached, but it should remain where it is as a much
needed layer of robustness/useful error reporting.
Conflicts:
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Duplicators.scala
commit f4c45ae204ce3ff3c16b19cab266d0b6515b6e0f
Author: Paul Phillips <paulp@improving.org>
Date: Fri Aug 31 10:49:24 2012 -0700
Rewrite of GenICode adapt.
Started for debuggability, stayed for clarify/performance.
Conflicts:
src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
commit 74842f72a0af485e5def796f777f7003f969d75b
Author: Paul Phillips <paulp@improving.org>
Date: Fri Aug 31 08:45:34 2012 -0700
Workaround for SI-6301, @specialize crasher.
SpecializeTypes is generating symbols with overloaded types
which then proceed to crash in CleanUp or GenICode. Until I
or someone works out why that is, take a look in case the
overload is easily disambiguated by the argument list arity,
in which case warn and proceed.
|
| |
| |
| |
| |
| |
| |
| | |
This commit shortens expressions of the form `if (settings.debug.value)` to
`if (settings.debug)` for various settings. Rarely, the setting is supplied
as a method argument. The conversion is not employed in simple definitions
where the Boolean type would have to be specified.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sifted through extraneous methods trying to find consistency,
consolidating and deprecating as I went. The original motivation
for all this was the restoration of LOCAL_SUFFIX to originalName,
because:
It looks like in an attempt to make originalName print
consistently with decodedName, I went a little too far and
stripped invisible trailing spaces from originalName. This
meant outer fields would have an originalName of '$outer'
instead of '$outer ', which in turn could have caused them to
be mis-recognized as outer accessors, because the logic of
outerSource hinges upon "originalName == nme.OUTER".
I don't know if this affected anything - I noticed it by
inspection, improbably enough.
Deprecated originalName - original, compared to what? - in
favor of unexpandedName, which has a more obvious complement.
Introduced string_== for the many spots where people have
given up and are comparing string representations of names.
A light dusting of types is still better than nothing.
Editoral note: LOCAL_SUFFIX is the worst. Significant trailing
whitespace! It's a time bomb.
|