| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |/ / / |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
See t5452 for disabled/neg/t5452 and disabled/pos/spurious-overload
I give up, review by @hubertp.
|
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 2b731911e97a281e324060099631e2374b2144ec.
|
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit a725bf982c06e16c5d533ea6b2227b726db4f7e4.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This reverts commit 0d315d652ae34e1c4cf1098cc753a43d4862e362.
I forgot Code had a big warning label saying "don't use me."
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
There's a deprecation process to follow before removing stuff.
scala.reflect.Code isn't even deprecated in 2.9.1.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Also modified size computation for Ctrie so that concurrent
`size` invocations can be parallelized more efficiently.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Size of the Ctrie is now cached and only recomputed for those parts
of the Ctrie that changed since the last snapshot.
|
| |/ /
|/| | |
|
|\ \ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
An object in a subclass would silently override an inherited
method, then throw a CCE at runtime. I blamed this on matchesType
and altered it accordingly. There's a pretty extensive test case
which reflects my expectations. Review by @odersky please.
Closes SI-5429.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
It was not desired.
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now it copies in the current versions of BoxesRunTime and ScalaRunTime
and applies patches to them, and the whole build is automated.
# This is the only thing I actually typed, the rest is fancy echo.
$ test/instrumented/mkinstrumented.sh build
% rm -rf /scratch/trunk1/test/instrumented/classes
% cp /scratch/trunk1/test/instrumented/../../src/library/scala/runtime/BoxesRunTime.java /scratch/trunk1/test/instrumented/../../src/library/scala/runtime/ScalaRunTime.scala /scratch/trunk1/test/instrumented/library/scala/runtime
% patch BoxesRunTime.java /scratch/trunk1/test/instrumented/boxes.patch
patching file BoxesRunTime.java
% patch ScalaRunTime.scala /scratch/trunk1/test/instrumented/srt.patch
patching file ScalaRunTime.scala
Hunk #3 succeeded at 63 (offset 23 lines).
Hunk #4 succeeded at 78 (offset 23 lines).
Hunk #5 succeeded at 81 (offset 23 lines).
Hunk #6 succeeded at 96 (offset 23 lines).
% /scratch/trunk1/test/instrumented/../../build/pack/bin/scalac -d /scratch/trunk1/test/instrumented/classes /scratch/trunk1/test/instrumented/library/scala/runtime/BoxesRunTime.java /scratch/trunk1/test/instrumented/library/scala/runtime/ScalaRunTime.scala
% javac -cp /scratch/trunk1/test/instrumented/../../build/pack/lib/scala-library.jar -d /scratch/trunk1/test/instrumented/classes /scratch/trunk1/test/instrumented/library/scala/runtime/BoxesRunTime.java
% cd /scratch/trunk1/test/instrumented/classes
% jar cf instrumented.jar .
% mv -f instrumented.jar /scratch/trunk1/test/instrumented/../../test/files/speclib
/scratch/trunk1/test/files/speclib/instrumented.jar has been created.
|
|\ \ \ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
If this looks hacky, that's because it is.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Closes SI-5446.
I am morally certain that fixes of this nature could be
performed by someone who has logged fewer than ten thousand
hours with the compiler.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Why is calling the error function not enough to register the error, why
does "setError(tree)" have to be called as well? That was the cause of
this particular stackoverflow. In ContextErrors I see lots of methods
which call setError and lots more which do not, and frankly it's all
pretty terrifying.
There is zero documentation attached to setError. Maybe there's an
explanation somewhere I'm not seeing.
Review by @hubertp.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix for trait/impl renaming in 5cbd7d06eb was incomplete.
Looks more complete now.
|
| | | |
| | | |
| | | |
| | | | |
Some day, outlawed!
|
| | | |
| | | |
| | | |
| | | | |
Review by @scalamacros.
|
|\ \ \ \ |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
'scalamacros/pullrequest/5229' into develop
|
| |/ / / |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Originally we thought that macros declared inside objects should not
provide _this to their bodies.
However, it: 1) contradicts vanilla Scala rules, according to which
both class and object methods can use this, 2) imposes unnecessary
burden on macro developers without providing any conveniences to us.
Review by @odersky.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Lazy accessors have the same essential problem as described in
recent commit messages, so this still doesn't work:
def f() = { case class Bob(); Bob } ; lazy val g = f
On the whole I'm trying to solve this at the wrong level. The derived
accessor methods and fields of a declaration should not ever wander far
enough apart that there is any challenge in reconciling them. (The same
is true for case classes/objects.) They're dependent synthetics who know
about one another from the beginning, all we have to do is not forget.
In the meantime, test case.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
What's improbable about 29f933b60 is that a good chunk of the commit
exists only so you can pass "mods" to the DefDef constructor. And then
the body isn't updated to use it, the parameter dies on the vine. That
was five years ago.
I logged when mods didn't match Modifiers(sym.flags) and there were
a bunch of differences, but I didn't see any interesting behavior
emerging. Still, I bet something changed somewhere (hopefully in the
fixy direction.)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Macro implementations now get type arguments as TypeTrees, not Types.
Keeping the situation with AnnotationInfos in mind, I decided to
go for the most future-proof solution. Another argument for this decision
is that we will most likely have to support untyped macros.
Review by @odersky.
|
|/ / / |
|
| | | | |
| \ \ | |
| \ \ | |
| \ \ | |
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
'scalamacros/pullrequest/removecodedotscala' and 'scalamacros/pullrequest/macrodoc' into develop
|
| | | | | | |
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a logical next step after deprecating and removing LiftCode:
https://github.com/scala/scala/commit/ffc2389840852a120fecd772206d55db9a79f30e
Now when Paul has uploaded a starr that doesn't need Code, Code$ and Code.lift
we can finally remove the last remaining pieces of the old reification logic.
|
| |/ / /
| | | |
| | | |
| | | | |
That was preventing the compiler API scaladoc from building
|
|\ \ \ \ |
|
| |/ / / |
|
|\ \ \ \
| |/ / /
|/| | | |
|