| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Fix for SI-5385.
|
| |
| |
| |
| |
| | |
Nodes which hit EOF with no whitespace afterward had
wrong position.
|
|\ \
| | |
| | | |
Deprecate all JVM 1.5 targets and make 1.6 default.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a check if deprecated target is being used. I put
that check into `checkDeprecatedSettings`. I tried to
invent some general mechanism for deprecating choices
in ChoiceSetting but I gave up eventually. It wasn't
worth it the complexity. Also, with current approach
I'm able to provide nice, customized deprecation
warning.
Make `jvm-1.6` a default backend.
Altered test for SI-5957 because it crashes the backend.
However, the problem is not with backend but with symbol
creation. We get two different symbols with the same
internal name and both are used in trees that reach
GenASM. See SI-6109 for details.
Review by @magarciaEPFL and @paulp.
|
|\ \ \
| | | |
| | | | |
Implement @static annotation on singleton object fields.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit introduces the `@static` annotation on fields of static singleton objects.
A static singleton object is a top-level singleton object or an object nested within
a static singleton object.
The field annotated with `@static` is generated as a true static field in the companion
class of the object. The initialization of the field is done in the static initializer of the
companion class, instead of the object itself.
Here's an example. This:
object Foo {
@static val FIELD = 123
}
class Foo
generates :
object Foo {
def FIELD(): Int = Foo.FIELD
}
class Foo {
<static> val FIELD = 123
}
The accessor in `object Foo` is changed to return the static
field in `class Foo` (the companion class is generated if it is
not already present, and the same is done for getters if `FIELD`
is a `var`).
Furthermore, all the callsites to accessor `Foo.FIELD` are rewritten
to access the static field directly.
It is illegal to annotate a field in the singleton object as `@static` if there is
already a member of the same name in `class Foo`.
This allows better Java interoperability with frameworks which rely on static fields being
present in the class.
The `AtomicReferenceFieldUpdater`s are one such example. Instead of having
a Java base class holding the `volatile` mutable field `f` and a static field containing
a reference to the `AtomicReferenceFieldUpdater` that mutates `f` atomically,
and extending this Java base class from Scala, we can now simply do:
object Foo {
@static val arfu = AtomicReferenceUpdater.newUpdater(
classOf[Foo], classOf[String], "f"
)
}
class Foo {
@volatile var f = null
import Foo._
def CAS(ov: String, nv: String) = arfu.compareAndSet(this, null, "")
}
In summary, this commit introduces the following:
- adds the `@static` annotation
- for objects without a companion class and `@static` members, creates a companion class
(this is done in `CleanUp`)
- checks for conflicting names and if `@static` is used on static singleton object member
- creates the `static` field in the companion class for `@static` members
- moves the field initialization from the companion object to the static initializer of
the class (the initialization of `@static` members is bypassed in the `Constructors` phase,
and added to static ctors in `CleanUp`)
- all callsites to the accessors of `@static` are rewritten to access the static fields directly
(this is done in `GenICode`)
- getters and setters to `@static` fields access the static field directly, and the field in the
singleton object is not emitted (this is done in `GenICode`)
- changes in `GenJVM`, `GenASM` - now computing local var indices in static initializers
as well - this was an oversight before, now is necessary
Future work: allow the `@static` annotation on methods as well - this will
be added in a future commit.
Review by @odersky, @dragos, @paulp, @heathermiller.
|
|\ \ \ \
| | | | |
| | | | | |
SIP-14 - Fix critical Java compatibility issue in scala.concurrent.Await
|
| | | | |
| | | | |
| | | | |
| | | | | |
Patch contributed by @viktorklang
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-6104 support This pattern
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This(name) is treated just like Ident(name)
apparently this pattern was used in 2.9 code,
though I'm not sure it's spec'ed
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Fix a bunch of scaladoc issues: SI-3314 SI-4888 SI-5235 SI-5558 SI-4324 SI-5780 SI-4887 SI-3695 SI-4224 SI-4497 SI-5079 SI-6073 SI-5533 SI-5784
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
@template and @documentable are now synomims.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Group class members based on their semantic relationship. To do this:
- @group on members, only need to do it for the non-overridden members
- -groups flag passes to scaladoc, groups="on" in ant
- @groupdesc Group Group Description to add descriptions
- @groupname Group New name for group
- @groupprio Group <int> (lower is better)
See test/scaladoc/run/groups.scala for a top-to-bottom example
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Normally scaladoc won't generate template pages for anything other than
packages, classes, traits and objects. But using the @template
annotation on {abstract,alias} types, they get their own page and take
part as full members in the diagrams. Furthermore, when looking for the
companion object, if a value of type T is in scope, T will be taken as
the companion object (even though it might be a class)
All templates, including types are listed on the left navigation pane,
so now adding @template to String can get scaladoc to generate (a
no-comments) page for java.lang.String.
The {abstract, alias} type icons need to be updated -- I just took the
class icons and added a small x to them -- but they shoud be something
else (maybe an underscore?)i
TO USE THIS PATCH:
<pre>
/** @contentDiagram */ // tells scaladoc to create a diagram of the
// templates contained in trait Base
trait Base {
/** @template */ // tells scaladoc to create a page for Foo
type T < Foo
trait Foo { def foo: Int }
}
/** @contentDiagram */
trait Api extends Base {
/** @template */
override type T <: FooApi
trait FooApi extends Foo { def bar: String }
}
</pre>
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
for SI-5784. This commit has been checked with tools/scaladoc-compare
and the only difference is that the containing entities in the index
are not duplicate anymore, which solves yet another bug we did not
know about. :)
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The known type class descriptions give you a humanly-understandable
explanation for [T: TypeClass] in the implicit conversions. For
example [T: Integral] will tell you that T must be an integral type
such as Integer and co.
Now that the reflection dust settled, I can actually add the test to
make sure the well-known type classes are intercepted and explanations
are given instead of the usual "the type T is context-bounded by
TypeClass"
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Adds the ability to link to members, classes and objects in scaladoc.
The links can now be either qualified names or relative names, they
both work. See the test/scaladoc/resources/links.scala for a usage
example. Also introduced -no-link-warnings scaladoc flag, in case the
build output gets swamped with link warnings.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Based on an inital patch by Nada Amin. Rewrote some of the code to
compress it a bit.
Also fixed a problem that was affecting the prefix printing for
typerefs: type parameter and existentials won't get prefixes. While
I can imagine cases where you'd want to see where they come from,
you can always hover over them and see their origin.
Also added support for pretty-printing ThisTypes, SuperTypes and
SingleTypes (with links)
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This was a long-standing issue in scaladoc: It was unable to
disambiguate between entries with the same name. One example is:
immutable.Seq:
trait Seq[+A] extends Iterable[A] with Seq[A] ...
What's that? Seq extends Seq? No, immutable.Seq extends collection.Seq,
but scaladoc was unable to show that. Now it does, depending on the
template you're in. Prefixes are relative and can go back:
-scala.collection.Seq has subclasses *immutable.Seq* and *mutable.Seq*
-scala.immutable.Seq extends *collection.Seq*
Unfortunately the price we pay for this is high, a 20% slowdown in
scaladoc. This is why there is a new flag called -no-prefixes that
disables the prefixes in front of types.
Btw, it also fixes the notorious "booleanValue: This member is added by
an implicit conversion from Boolean to Boolean ...". That's now
java.lang.Boolean, so it becomes clear.
Conflicts:
src/compiler/scala/tools/nsc/doc/model/diagram/DiagramFactory.scala
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
SI-3448 partial fix:
This enables a workaround for the fact that Map takes two type params
while $Coll takes only one. But it doesn't fix the problem though,
as there's one more piece missing from the puzzle - we need to adjust
the `Coll`s in {immutable, mutable, concurrent}.Map to something that
makes sense for the usecase. And that's not possible. But I'm
committing this nevertheless, maybe other projects can benefit from it.
And for SI-3448, the solution lies in automatic usecase generation,
whenever that will be ready.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
case class C(i: Int)(b: Boolean) would appear uncurried in scaladoc:
case class C(i: Int, b: Boolean)
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This bug was fixed by the model upgrade in c11427c1. Test case confirmation.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This bug was fixed by the model upgrade in c11427c1. Test case confirmation.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Related to SI-3314, where we started showing inherited templates
that were normally not documented. This patch corrects a problem
in parentTypes that was preventing inherited templates from being
displayed in diagrams.
Also renamed:
PackageDiagram => ContentDiagram
ClassDiagram => InheritanceDiagram
which should have been done much earlier
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
And adds support for linking to class members, only usable from the
model factory now, so no links to members from the doc comment yet,
sorry. But it fixes the Enumeration problem once and for all!
Also corrected the inTpl for members obtained by implicit conversions,
so they're in the correct template and the comment variable expansion
is done from the correct (but different) template.
Review by @kzys.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The bug is related to a couple of other annoyances, also fixed:
- usecases without type params were crashing scaladoc due to a change
in the PolyTypes class (not allowing empty tparams list)
- properly getting rid of backticks (even if the link is not valid)
- correct linking for usecases with $Coll = `immutable.Seq`
(the symbol searching algorithm was too of restrictive, now we search
the entire ownerchain - and the empty package at the end)
- give a warning if the type lookup fails
- finally, added a $Coll variable to List, for some reason it wasn't
there and we were getting immutable.Seq as the result of use cases.
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
SI-5999 consistent behavior for c.reify and c.universe.reify
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
After a discussion on a reflection meeting on Jul 17
we concluded that we should split staticModule into
staticModule and staticPackage to remove the ambiguity
between packageless objects and packageless packages
(more in the comments in the body of the commit).
The motivation is verbosely outlined in the comments,
but the bottom line is that Scala allows packages and
packageless objects to have the same name within the same program.
Therefore at times we need to disambiguate, hence the introduction
of the staticPackage method.
As of such staticModule no longer works for packages.
In the same fashion staticPackage doesn't work for modules.
This is done to ensure robustness of reification.
I would like to do the same for getModule in Definitions,
but we have to maintain backward compatibility. That's why I retained
the old behavior, but replaced getModule invocations with getPackage
where appropriate to be in line with staticModule and staticPackage.
Another important thing that follows from the discussion is that
both staticClass and staticModule prefer parent packages over parent objects
in cases of ambiguity. Say, if we have the following snippet of code:
object B { class C } next to package B { class C }
then staticClass("B.C") will never even consider a C inside the object B.
This is how scalac operates, so we decided to be consistent here.
Finally reification logic got changed to distinguish between
staticModule and staticPackage, and to allow for the fact that
staticClass and staticModule prefer parent packages to parent objects.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Currently there are discrepancies between the behavior of
c.reify and c.universe.reify.
First step in fixing these problems is removing the duplication in the API.
That's why I'm cutting away the Context.reify shortcut.
Context.reify is a magic macro, hardwired in the fast track mechanism, so
removing it requires redeploying the starr (because an old starr will
crash if launched on sources that don't contain Context.reify).
To cleanly redeploy a starr I've left a Context.reify stub in sources,
but hidden it behind a `protected` modifier. When starr is redeployed
(in a subsequent commit) the stub will be removed.
I've also updated the tests to use c.universe.reify instead of c.reify.
This will break some of them, because c.universe.reify uses a standard
compiler mirror, which unlike a macro mirror doesn't like packageless classes.
That's an annoyance, but I think having clean separation of commits
is more important that being 100% consistent.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-5856 enables use of $this in string interpolation
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This pull request fixes SI-5856. The scanner has been modified
to return the correct token if keywords appear in $-expressions.
The parser has been modified to issue an error and to only accept
$<identifier>, $this and $block.
|
|\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | | |
SI-5739 store sub-patterns in local vals
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Also closes SI-5158 (debuggability), SI-6070 (soundness).
To improve both debuggability and soundness,
we now store the result of an extractor (user-defined and synthetic)
in local variables.
For the case class case, this also fixes the soundness bug SI-6070,
as this prevents post-match mutation of bound variables.
The core of the refactoring consisted of introducing the PreserveSubPatBinders
trait, which introduces local variables instead of substituting symbols
for the RHS of those variables (so this can be seen as reverting the premature optimization
of inline the case-class getters into the case body).
Since TreeMakerToCond fuses the substitutions performed in a match to find out
which symbolic values binders evaluate to, masquerade PreserveSubPatBinders's
binding of subPatBinders and subPatRefs as the corresponding substitution.
Consider `case class Foo(bar: Int)`, then `case y@Foo(x) => println(x)`
gives rise to `{val x = y.bar; println(x)}` (instead of `println(y.bar)`),
and `subPatternsAsSubstitution` pretends we still replace `x` by `y.bar`,
instead of storing it in a local variable so that the rest of the analysis need not be modified.
Misc notes:
- correct type for seq-subpattern
- more error resilience (ill-typed patterns sometimes slip past the typechecker -- reopened SI-4425)
TODO: come up with a more abstract framework for expressing bound symbols and their values
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
fixes field mirrors and also improves docs and exceptions for all mirrors
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Factors out error raising code and introduces a special exception class
for Scala reflection errors.
Also adds membership sanity checks to reflectXXX. Previously
reflectField, reflectMethod, reflectClass and reflectModule
in InstanceMirror didn't check that the symbols being passed to them
actually correspond to some member of the related class.
|
| | |_|_|_|_|_|/
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
reflectField now accepts getters and setters along with the field symbols,
it also checks whether a field has a reasonable binary representation
(this is necessary, because ctor parameters that are unused outside of their
declaring constructors don't get compiled down to Java fields/methods).
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
SI-4897 derive expected value from single type
|
| | |_|_|_|_|_|/
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
when the type in a type test is, say, `C.this.A.type`,
must use the corresponding term `C.this.A` to test for equality
if you use the naive REF(<C.this.A.type>.symbol), you'll
get a path like `OwnerOfA.this.A`,
where `OwnerOfA` might be a superclass of `C`, and
explicitouter won't like that
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Critical bugfixes/leak fixes/API corrections + ScalaDoc for SIP-14
|
| | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \
| |/ / / / / / / /
|/| | | | | | | | |
test case closes SI-6047
|
| | |/ / / / / /
| |/| | | | | |
| | | | | | | |
| | | | | | | | |
The bug is not reproducible both in M4 and in M5.
|
|\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | | |
SI-6086 magic symbols strike back
|
| | |_|_|/ / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Some of the symbols inside the compiler get created on the fly,
because there are no physical entities in classfiles corresponding to them.
This curious fact needs to be taken into account when loading symbols,
so that the magic symbols get correctly loaded by reflective mirrors.
magicSymbols (as defined in Definitions.scala) include not only
top-level classes, but some other stuff (e.g. String_+ or methods on Any).
Hence a filtering was done to exclude the stuff that's irrelevant
to reflective symbol loading.
Unfortunately a filter was configured to accept only _.isClass,
which consequently ruled out scala.AnyRef (that is a type alias).
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-6092 don't leak in LazyAnnotationInfo, don't lift try{}finally{}
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
which a try-catch is lifted
out to an inner method.
Less known fact: lazy values null-out their dependent values is their accessed only from
their initializer. The analysis is not context-dependent (meaning the owner where a reference
happens needs to be exactly that lazy value).
* Removed no-op code around positions in `LazyAnnotationInfo`
* Don't lift expressions that have no `catch` clause
The two changes combined fix a memory leak that's been plaguing the IDE: an annotation
(even when forced) would hang on to a namer, through the outer field of its call-by-name
parameter.
The test for the memory leak is in the IDE project (couldn't find a simple way to reproduce it outside
the IDE), but there's a test checking that the field is null after initialization.
|
|\ \ \ \ \ \ \ \
| |_|_|_|_|_|/ /
|/| | | | | | | |
SI-6089 better tail position analysis for matches
|