| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
And also non-exhaustive matches.
And added -nowarn to the build options for scalacheck,
we don't need to hear the warnings for code we aren't
able to fix.
|
| |
|
|
|
|
|
|
|
|
| |
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-6075 cleans up api.StandardNames
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I removed most of the stuff from api.StandardNames and reorganized all names.
In the new scheme of things (as documented in the comments to StandardNames):
1) base.StandardNames contains names necessary for building trees. For example,
tpnme.WILDCARD_STAR is necessary to build some invocations of varargs methods,
and nme.CONSTRUCTOR is necessary to build invocations of constructors.
2) api.StandardNames hosts names that are core to doing reflection. E.g.,
to get to a package object, you need to find a member named nme.PACKAGE,
to strip off the whitespace from the name of an underlying field of a val,
you need nme.LOCAL_SUFFIX_STRING.
Note that we don't need nme.MODULE_SUFFIX_STRING, because module name mangling
is encapsulated in java mirrors.
|
|\ \
| | |
| | | |
SI-6112 exposes symbol mutators in macro universe
|
| |/
| |
| |
| |
| |
| |
| |
| | |
In makro.Universe we expose the most hardcore fragments of the compiler API
that don't make sense / can't be made use of in runtime reflection API.
makro.Universe is already refining Tree to include setters for
symbols, types and positions. Now we bring Symbol up to speed.
|
|\ \
| | |
| | | |
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-6058 makes JavaMirror caches weak
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
As discussed on reflection meeting on 2012/07/19, runtime reflection caches
need to be weak. This way we prevent leaks in long-running reflection-based
applications (the primary target here being SBT).
|
|\ \ \
| |/ /
|/| | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Stop recording symbols once the shutdown hook is triggered
so that the symbols created in the act of dumping the symbols
do not pollute the view of what symbols were created naturally.
|
| | |
| | |
| | |
| | | |
"If the names don't fit, do not commit!"
|
|\ \ \
| | | |
| | | | |
[doc] Fix example of `Ordering.on` usage.
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | | |
SI-6122: Small changes to reflection API to make it safe for IDE use.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
* Removed `typeSymbol` and `termSymbol` from `reflect.api.base`, and pushed them down to
`reflect.api`.
* extracted `TypeTree.symbol` to a top-level method so it can be overridden in other layers
|
|\ \ \ \
| | | | |
| | | | | |
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.
|
|\ \ \
| |_|/
|/| | |
Handle multiple packages in one source file in the presentation compiler.
|
| |/
| |
| |
| |
| |
| |
| | |
The PC symbol loader would mistakenly refuse to enter symbols if more than one package declaration occurred
in the same file. This has become common practice:
package object foo { … }
package foo { … }
|
|\ \
| | |
| | | |
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
|
| | | |
|
|\ \ \
| | | |
| | | | |
SI-6089 pt2: _ is tailpos in `_ || _` and `_ && _`
|
| | | |
| | | |
| | | |
| | | |
| | | | |
pull #939 made tail position detection for matches more strict to fix SI-6089,
but became too strict: need to include the tail positions `_` in `_ || _` and `_ && _`.
|
|\ \ \ \
| |_|_|/
|/| | | |
Scaladoc: Removing forgotten debugging info
|
| | | |
| | | |
| | | |
| | | | |
(blush)
|
|\ \ \ \
| |_|/ /
|/| | | |
address "this would catch all throwables" warnings
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
original patch by @odersky in #955 -- criterion for the refactor:
"catch Throwable as long as there's no obvious control flow exception going through the catch
and the caught exception is processed further"
rebased & updated with review comments in #955 and #954
|
|\ \ \ \
| | | | |
| | | | | |
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.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When assertion fails, let's provide
the context.
|
| | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It looks like scala.tools.ant.Scalac class had
a stale list of allowed targets. Made it in sync
with what compiler supports.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Implement @static annotation on singleton object fields.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The upcoming `findMember` optimizations should ensure that this
is fast enough.
|