| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
| | | | |
| | | | |
| | | | | |
From the extempore archive of already implemented things.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Found a better elidable implementation which is robust against other
parts of the compiler doing their things. Calls to elidable methods are
replaced with zero of the same type. Elidable methods themselves remain
in place, but with their body replaced with a zero of the method return
type.
Thus is everything to be found where it is expected to be found, but
nothing will be found where nothing ought to be found. Nothing of course
will never be found.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On epfl jenkins, elidable.scala fails with:
[partest] java.lang.VerifyError: (class: Test$, method: main signature: ([Ljava/lang/String;)V) Unable to pop operand off an empty stack
[partest]
[partest] at Test.main(elidable.scala)
Strangely it is fine for me on OSX with either apple's jvm or openjdk.
Since tests were not running for a while I don't know which of the recent
elidable commits is responsible, so given present time demands all I
can do is revert them all.
Revert "Fix for SI-5215: scalac crash when @elidable used in trait"
This reverts commit 5e52ce9a13f12ef159e25ac80c6be2803ec48950.
Revert "Fix for SI-5215 part 2: generate return value when eliding method calls"
This reverts commit 61c9b4f01d99a81e15391b270bd1b5a895f65ffd.
Revert "Eliminating duplication in zero creation."
This reverts commit fbb7865e137e83660257fdc79d19d29ff39c775b.
Revert "Disallow eliding when Nothing is expected"
This reverts commit f26a47c4e8bda2f6c689b4e9b0bb5c64ccf4c699.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Running the test produces the following error in 2.9.1:
java.lang.VerifyError: class com.restphone.IsList$ overrides final method canEqual.
Works fine in 2.10.0-M2
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
The elision is now done by not emitting method calls (it was done by removing the elidable methods).
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
While [@specialized A] already tries to include specialization,
a bug in specializedOn prevented this from happening: any empty
list could mean that the type var was unspecialized, or that it
was specialized on everything.
The fix is to have this function create the full list of symbols
in the case where the @specialized annotation doesn't explicitly
include any types.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Some in pending, some in files. Closes SI-4770.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
A reimagining of erik's patch in 1df4fc6e59 . He did the hard
part, this is the batman reboot. I added more tests and tried
to make the anyref caching code less fragile.
|
| |\ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The basic problem here was that generic type params were getting
confused between the various specialized subclasses. For instance,
calling typeParamsSubAnyRef(A, C2$mcLI$sp) might return the wrong
specialized type param, e.g. C2$mcLZ$sp.A$sp (note the Z instead
of the I).
The fix is to cache with both the sym (A) and also the clazz
(C2$mcLI$sp). This may resolve a whole host of other obscure
AnyRef specialization problems.
|
| |\ \ \ \ \
| | |/ / / /
| |/| | | | |
|
| | | | | | |
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
don't consider the matcherror-throwing catch-all case (generated by virtpatmat) a default case
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
catch handlers are now also translated by the virtualizing pattern matcher
emit type-based switches when possible, fallback to catch-all with full pattern match
(the logic used to emit constant-based switches was generalized to type-based switches,
abstracting out how to refer to the scrutinee and the shape of a default/catch-all case)
this was the last missing piece of essential functionality
now the virtualizing pattern matcher and the old one are mutually exclusive:
-Yvirtpatmat disables the old matcher logic completely
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
At least for the value of fix which means "better than it was in
2.9." I accidentally spent a long while trying to fix something I didn't
realize I hadn't broken. But then I lucked into partially fixing it, so
that's good news.
See run/t5488-fn.scala if you want to see what still doesn't work.
(It's covered at SI-4770, which is now reopened.) Closes SI-5488.
|
| | | | | | |
| | \ \ \ | |
| | \ \ \ | |
| | \ \ \ | |
| |\ \ \ \ \ \
| | | | |/ / /
| | | |/| | |
| | | | | | | |
'szabolcsberecz/synchronized-test' and 'non/si-5005-2' into develop
|
| | |/ / / /
| |/| | | | |
|
| | |/ / /
| | | | |
| | | | |
| | | | | |
This fix was previously only applied to hash sets.
|
| | | | | | |
| | \ \ \ | |
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
and 'scalamacros/pullrequest/multilineinterpolation' into develop
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously toolboxes used to typecheck their inputs before compiling.
Actually, the initial demo by Martin first typechecked the reified tree,
then ran it, which typechecked it again, and only then launched the
reflective compiler.
However, as observed in https://issues.scala-lang.org/browse/SI-5464
current implementation of typechecking is not always idempotent.
That's why we cannot allow inputs of toolboxes to be typechecked,
at least not until the aforementioned issue is closed.
This is not only a convention but also a check inside compileExpr.
|
| | |/ / / / |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also modified size computation for Ctrie so that concurrent
`size` invocations can be parallelized more efficiently.
|
| | |/ / /
| |/| | | |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The crickets at http://www.scala-lang.org/node/11901 were in
unanimous agreement that I should proceed as suggested.
- No arguments to @specialize gets you 10/10, not 9/10
- Fixed bugs in AnyRef specialization revealed by trying to use it
- Specialized Function1 on AnyRef.
- Changed AnyRef specialization to use OBJECT_TAG, not TVAR_TAG.
- Deprecated SpecializableCompanion in favor of Specializable,
which has the virtue of being public so it can be referenced
from outside the library.
- Cooked up mechanism to group specializable types so we don't
have to repeat ourselves quite so much, and create a few groups
for illustrative purposes. I'm not too serious about those names
but I used up all my name-thinking-up brain for the day.
- Updated genprod and friends since I had to regenerate Function1.
- Put tests for a bunch of remaining specialization bugs in pending.
Closes SI-4740, SI-4770, SI-5267.
|
| |\ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Direct compiler internals testing. It's really easy, you should probably
use it about 1000 times each. Look at the test:
run/existentials-in-compiler.scala
The checkfile contains the (string representations of the) actual
existentials from the compiler to make sure they correspond properly to
the ones in the source.
Existentials were being printed with wildcards too freely; this has been
tightened up.
|
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Annotations are now supported by the reifier:
* AnnotationInfos from symbols get transformed back into mods.
* AnnotatedTypes are retained and are reified along with AnnotationInfos.
Reification is no magic, and reification of annotations especially:
* Annotations cannot refer to symbols defined inside the quasiquote.
This restriction is due to the fact that we need to erase locally defined
symbols before reifying to make subsequent reflective compilations succeed.
However, while doing that, we also need to make sure that we don't make
resulting ASTs non-compilable by removing essential information.
This is tricky, and it more or less works for TypeTrees, but
not for annotations that can contain arbitrary ASTs.
For more details look into the comments to Reifiers.scala.
* Classfile annotations that contain array arguments and are applied to types,
i.e. the ones that generate AnnotatedTypes, cannot be reified.
This is because of limitations of manifest infrastructure.
Typechecking "Array(mirror.LiteralAnnotArg(...))" would require the compiler
to produce a manifest for a path-dependent type, which cannot be done now.
Review by @odersky.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
At some point in the past, trying to prevent deprection warnings from
being issue in triplicate in the repl, I suppressed too much output,
leading to a class of breakdowns where the failure would be swallowed
completely. This went on for far too long. The deprecation warnings
are back in triplicate for the moment, but the repl should now be less
"strong, silent type" and more emo.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There is a window of danger when multiple related elements are
being typed where something which is conceptually one thing can
slip into two things, and those two things can be incompatible
with one another. Less mysteriously, c478eb770d fixed this:
def f = { object Bob ; Bob } ; val g = f
But, it did not fix this:
def f = { case class Bob() ; Bob } ; val g = f
See test case pos/existentials-harmful.scala for an "in the wild"
code example fixed by this commit.
The root of the problem was that the getter and the field would each
independently derive the same existential type to describe Bob, but
those existentials were not the same as one another.
This has been the most elusive bug I have ever fixed. I want to cry when
I think of how much time I've put into it over the past half decade or
so. Unfortunately the way the repl works it is particularly good at
eliciting those grotesque found/required error messages and so I was
never able to let the thing go.
There is still a cosmetic issue (from the last commit really) where
compound types wind up with repeated parents.
Closes SI-1195, SI-1201.
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When performing an existential transform, the bounds produced by the
hidden symbols may contain references to the hidden symbols, but these
references were not accounted for. This was at the root of some bad
behavior with existentials.
If you've ever seen a message like this:
<console>:8: error: type mismatch;
found : B(in value res0) where type B(in value res0) <: A with ScalaObject
required: B(in value res0) forSome { type B(in value res0) <: A with ScalaObject; type A <: Object with ScalaObject }
...then you know what I mean.
Closes SI-4171, not quite yet on SI-1195, SI-1201.
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In the pursuit of simplicity and consistency.
- Method names like getType, getClass, and getValue are far too ambiguous,
both internally and especially with java reflection names. Methods which
accept or return scala symbols should not refer to them as "classes" in
the reflection library. (We can live with the FooClass convention for naming
the well-known symbols, it's names like "getClass" and "classToType" which
are needlessly conflationary.)
- Meaningless names like "subst" have to be expanded.
- We should hew closely to the terms which are used by scala programmers
wherever possible, thus using "thisType" to mean "C.this" can only beget confusion,
given that "thisType" doesn't mean "this.type" but what is normally called
the "self type."
- It's either "enclosing" or "encl", not both, and similar consistency issues.
- Eliminated getAnnotations.
- Removed what I could get away with from the API; would like to push
those which are presently justified as being "required for LiftCode" out of the core.
- Changed a number of AnyRefs to Any both on general principles and because
before long it may actually matter.
- There are !!!s scattered all over this commit, mostly where I think
the name could be better.
- I think we should standardize on method names like "vmSignature, vmClass" etc.
when we are talking about jvm (and ostensibly other vm) things.
There are a bunch more places to make this distinction clear (e.g.
Symbol's javaBinaryName, etc.)
- There is a lot more I want to do on this and I don't know where the
time will come from to do it.
Review by @odersky, @scalamacros.
|
| | | | | |
| | | \ | |
| | | \ | |
| | | \ | |
| | |\ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
'scalamacros/pullrequest/5334', 'scalamacros/pullrequest/5272' and 'VladUreche/issue/5287-cleanup' into develop
|
| | | |_|/ /
| | |/| | | |
|
| | | |/ /
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
New version of reification isn't susceptible to this bug.
The problem was with Code.lift generating not only a tree, but also
a manifest with the type of that tree. That led to an issue in the case
of the type of the manifest depending on a class declared inside the
quasiquote.
Now manifests in reification are gone, so is the problem.
|
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Major cleanup of reification:
* LiftCode phase has been removed
* Code has been deprecated and will be removed as we roll a new starr
* Logic related to type-directed lifting has been purged
scala.reflect.macro.Context#reify now provides the same services
as LiftCode provided (except that it returns Tree, not Code).
For testing purposes, I've retained the oh-so-convenient automagic lift.
test/files/codelib/code.jar now hosts Code.lift reimplemented in a macro,
so that the tests can continue working as if nothing has happened.
|
| | | |
| | | |
| | | |
| | | | |
Changed parameters in some tests to speed them up.
|
| | | |
| | | |
| | | |
| | | | |
Implemented Ctrie serialization. Improved hashcode computation.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Ctrie is a scalable concurrent map implementation that supports
constant time lock-free lazy snapshots.
Due to the well-known private volatile field problem, atomic
reference updaters cannot be used efficiently in Scala yet.
For this reason, 4 java files had to be included as well.
None of these pollute the namespace, as most of the classes
are private.
Unit tests and a scalacheck check is also included.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I guess I have to suck up the "C with Object" here in order
to get the "Array[T with Object]" I need in a different test.
Now all tests pass for reals.
|
| | | | |
|
|\ \ \ \
| | |/ /
| |/| /
| |_|/
|/| | |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
determine match strategy by typing `__match`
factored out the interface to generate code in this monad, cleaned up codegen a bit
no longer solving a context bound to determine the match strategy and the monad's type constructor
it's too expensive
don't consider implicits looking for __match
implicit search causes HUGE slowdowns -- now the overhead is about 4% compared to just assuming there's no __match in scope
to support virtualization&staging, we use the type of `__match.one` as the prototype for how to wrap "pure" types and types "in the monad"
pure types T are wrapped as P[T], and T goes into the monad as M[T], if one is defined as:
def one[T](x: P[T]): M[T]
for staging, P will typically be the Rep type constructor, and type M[T] = Rep[Option[T]]
furthermore, naive codegen no longer supplies type information -- type inference will have to work it out
optimized codegen still does, of course, and that's enough since we only bootstrap that way
TODO: improve the test (currently the condition is not represented)
|