| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Fixed SI-5603. Early definitions now get transparent positions.
|
| | |
| |
| |
| |
| |
| | |
This includes a fix for a minor problem described in #594 -
ensureNonOverlapping still focuses on default position when outside of early defs.
Review by @dragos, @odersky.
|
| |\ \
| | |
| | | |
Closes SI-5878
|
| | | |
| | |
| | |
| | | |
We need to impose an additional rule on value classes: They may not unbox directly or indirectly to themselves.
|
| |\ \ \
| |_|/
|/| | |
IDE improvements, with particular focus on making worksheets work.
|
| | | |
| | |
| | |
| | | |
Adds a raw string interpolator raw"..." which does not do any escape sequence processing.
|
| |\ \ \
| | | |
| | | | |
Partest instrumentation fixes
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Extend instrumenting infrastructure to instrument
classes in `instrumented` package. This is useful
because very often you need to put your classes
into non-empty package. E.g. inliner doesn't work
properly with empty package at the moment so in
order to test any behaviour we need to put classes
in some other package that is instrumented.
Added testing code for that to instrumentation
test-case.
Review by @phaller.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-6140 Scaladoc infinite recursion in wiki parser
|
| | |/ / /
| | | |
| | | |
| | | | |
introduced by dc70d1b7.
|
| |\ \ \ \
| | | | |
| | | | | |
Issue/4560
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Added all the known cases of failing self-types. Added tests for symbol
access (SI-4601) as well which should now be fixed for all of the same cases
as well.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Following this commit are reversions of three prior commits which
introduced difficulties of their own, plus extra tests for this
issue and SI-4601, all of which I pinched from jrudolph.
Maybe there was a good reason for some of the complicated code
related to this ticket. I took the naive position that if we avoided
generating a method call to a particular receiver if the receiver
has no such method, we would encounter fewer NoSuchMethodErrors.
I would believe one can construct a scenario which this doesn't
handle correctly, but it's hard to believe this isn't a big
improvement. Review by @jrudolph, @odersky.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-6142: warn @inline-methods ending up not inlined (rightfully or not)
|
| | | |/ / /
| |/| | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-5958 This deserves a stable type
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`this` (or the self variable) passed as an actual argument to a method
should receive a singleton type when computing the method's resultType
this is necessary if the method's type depends on that argument
|
| | |_|_|/
|/| | |
| | | |
| | | |
| | | | |
... in a less nice way than I would like. Essentially, we mask type errors at later stages that arise from comparing existentials and skolems because we know that they are not tracked correctly through all tree transformations. Never mind that all these types are going erased anyway shortly afterwards. It does not smell nice. But as I write in the comment, maybe the best way out is to
avoid skolems altogether. Such a change by far exceeds the scope of this pull request however.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't warn on "uncheckable" type patterns if they can be
statically guaranteed, regardless of their runtime checkability.
This covers patterns like Seq[Any] and lots more.
Review by @adriaanm.
|
| |\ \ \
| |/ /
|/| | |
SI-4440 workaround: avoid outer accessor that'll vanish
|
| | |/
| |
| |
| |
| |
| | |
outer accessors of final classes are dropped in constructors
apply some foresight in explicit outer and replace those doomed outer checks by `true`
(since this is unfortunate, we generate an unchecked warning)
|
| |\ \
| | |
| | | |
SI-6117 regression involving import ambiguity.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Today I learned that
foo.member("bar") != foo.member("bar")
if bar is overloaded, because each lookup of an overloaded member
creates a new symbol (with equivalent OverloadedTypes.) How should symbols
be compared so these do not appear unequal? Is there a method which
unpacks the alternatives and compares them individually? It seems likely
there are additional bugs which arise from not covering this case.
Since this bug is in the context of importing, if the prefixes are
identical then I can compare the names instead of the symbols and this
issue goes away. But for the rest of the time during which one might
encounter overloaded symbols, that would be a very lossy operation,
since the overloaded symbol might be encoding any subset of the members
with that name.
There are lots of references to "OverloadedSymbol" in the comments of
various methods in Types, but no such class is visible in the history.
If we had such a thing, we could refine its equals method to recognize
equivalent overloads.
Review by @odersky.
|
| |\ \ \
| | | |
| | | | |
Improve unchecked warnings.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Spurious test was not good. Better test avoids suppressing
some legitimate warnings. Review by @moors.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-6111 accept single-subpattern unapply pattern
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
An extractor pattern `X(p)` should type check for any `X.unapply`/`X.unapplySeq`
that returns an `Option[_]` -- previously we were confused about the case where
it was an `Option[(T1, ... , Tn)]`. In this case, the expected type for the
pattern `p` is simply `(T1, ... , Tn)`.
While I was at it, tried to clean up unapplyTypeList and friends (by replacing them by extractorFormalTypes).
From the spec:
8.1.8 ExtractorPatterns
An extractor pattern x(p1, ..., pn) where n ≥ 0 is of the same syntactic form as a constructor pattern.
However, instead of a case class, the stable identifier x denotes an object which has a member method named unapply or unapplySeq that matches the pattern.
An unapply method in an object x matches the pattern x(p1, ..., pn) if it takes exactly one argument and one of the following applies:
n = 0 and unapply’s result type is Boolean.
n = 1 and unapply’s result type is Option[T], for some type T.
the (only) argument pattern p1 is typed in turn with expected type T
n > 1 and unapply’s result type is Option[(T1, ..., Tn)], for some types T1, ..., Tn.
the argument patterns p1, ..., pn are typed in turn with expected types T1, ..., Tn
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Changed behavior so that when determining the target variance of a method parameter,
the variance in formals comes first. If variance is still undecided by that,
the variance in the result type is used as a secondary criterion.
(This is also done when determining prototype type params.)
|
| |\ \ \
| |/ /
|/| | |
SI-6090 correct rewriting of overloaded value class ==
|
| | | |
| | |
| | |
| | | |
Sharpens the test so that only Object_== and Object_!= methods on valueclasses may be rewritten in posterasure, whereas user-defined methods are not rewritten.
|
| | |/
|/|
| |
| | |
test that matchEnd that's an argument of || that's in tail position is in tail position
|
| |\ \
| |/
|/| |
SI-1832 consistent symbols in casedef's pattern&body
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the only change to typedBind in this commit (beyond refactoring to keep my eyes from bleeding),
is explained by the added comment:
have to imperatively set the symbol for this bind to keep it in sync with the symbols used in the body of a case
when type checking a case we imperatively update the symbols in the body of the case
those symbols are bound by the symbols in the Binds in the pattern of the case,
so, if we set the symbols in the case body, but not in the patterns,
then re-type check the casedef (for a second try in typedApply for example -- SI-1832),
we are no longer in sync: the body has symbols set that do not appear in the patterns
since body1 is not necessarily equal to body, we must return a copied tree,
but we must still mutate the original bind
|
| |\ \
| | |
| | | |
Removes redundant outers
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Widens the criterion when outer fields can be omitted. It used to be that sub- and superclass had to be enclosed by the same outer class. Only in that case was the outer field of the class omitted. We now omit if subclass is contained in an outer class that is itself a subclass of the superclasses outer class.
See test case "outertest.scala" for an example.
|
| |\ \ \
| | | |
| | | | |
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>
|
