| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
The `neg` test was already working since `SerialVersionUID`
was changed to a `ClassFileAnnotation`; the `run` test only
started working since the recently preceding commit that
made a compensatory test in the backend.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To date, we've been hesidant to offer any guarantees about
Java serialization of standard library types among heteregenous
Scala versions.
Nonetheless, we have added `SerialVersionUID` annotations to
parts of the standard library, to offer some stability. This
protects against two winds of change: automatic calculation of
this UID might differ between JVM versions, or it might differ
due to otherwise immaterial changes to the library in Scala
releases.
With this commit, we strengthen the guarantees. Classes
marked with `SerialVersionUID` will be serialization compatible
within minor releases of Scala. This is backed up by the
enclosed test.
After major releases, we reserve the right to break this.
But the test will serve to avoid *accidental* changes.
Specifically, the test case checks:
- deserialize(serialize(x)) == x
- serialize(x) is stable over time
I have included values of all types marked with `@SerialVersionUID`
in the library. For some types, I've added variations in the
values to exercise different subclasses, such as `Set1` / `Set2`.
This found that that the serialized form of predefined `ClassTags`
included the cached identity hash code and failed the stability
test. This wasn't an issue for correctness as they also provide
`readResolve`, but I marked those fields as `@transient` in any
case to comply with the test expectations.
That whole area is good example of a serialization worst-practice:
using anonymous classes in code like:
val Object: Manifest[java.lang.Object] = new PhantomManifest[...](...) {
private def readResolve(): Any = Manifest.AnyVal
}
... will lead to instability if these declarations are shifted around
in the file. Named classes would be preferred. I've noted this in a
TODO comment for 2.12.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In PR #1673 / 4267444, the annotation `SerialVersionId` was
changed from a `StaticAnnotation` to `ClassFileAnnotation` in
order to avoid silently ignoring non-literal UIDs like:
@SerialVersionUID(0 - 12345L) class C
And to flag non-constant UIDs:
@SerialVersionUID("!!!".length)
While this indeed was fold constants, the change was incomplete.
The compiler API for reading the argument from a `ClassFileAnnoation`
is different, on must look for a `LiteralAnnotArg`, rather than a
`Literal`.
This commit:
- amends the backend accordingly
- removes relevant duplication between `GenASM` and `GenBCode`
- tests that the static field is generated accordingly
This will mean that we will break deserialization of objects from
Scalal 2.11.0 that use this annotation.
|
| |\ \
| | |
| | | |
SI-7852 for GenBCode
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
Avoid null checks for "someLiteral".== and SomeModule.==. This has
been implemented in GenICode in #2954.
Introduces a trait to share code between GenICode and GenBCode. This
is just a start, more such refactorings will come quite certainly.
|
| |\ \ |
|
| | |\ \
| | | |
| | | | |
SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
And update the java `ClassFileParser` to create distinguished
`StubClassSymbol`s, rather that a regular `ClassSymbol`s, when
encountering a deficient classpath. This brings it into line
with `Unpickler`, which has done as much since a55788e275f.
This stops the enclosed test case from crashing when determining
if the absent symbol, `A_1`, is a subclass of `@deprecated`.
This is ostensibly fixes a regression, although it only worked in
`2.10.[0-3]` by a fluke: the class file parser's promiscious
exception handling caught and recovered from the NPE introduced
in SI-7439!
% javac -d /tmp test/files/run/t8442/{A,B}_1.java && qbin/scalac -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala && (rm /tmp/A_1.class; true) && scalac-hash v2.10.0 -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala
warning: Class A_1 not found - continuing with a stub.
warning: Caught: java.lang.NullPointerException while parsing annotations in /tmp/B_1.class
two warnings found
|
| | |\ \ \
| | | | |
| | | | | |
[nomaster] backports 609047ba37
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MemberDefs alone can't be typechecked as is, because namer only names
contents of PackageDefs, Templates and Blocks. And, if not named, a tree
can't be typed.
This commit solves this problem by wrapping typecheckees in a trivial block
and then unwrapping the result when it returns back from the typechecker.
(cherry picked from commit 609047ba372ceaf06916d3361954bc949a6906ee)
|
| |\| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
bincompat-forward.whitelist.conf
src/reflect/scala/reflect/runtime/JavaMirrors.scala
|
| | |\ \ \
| | | | |
| | | | | |
SI-8196 Runtime reflection robustness for STATIC impl details
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Which was fixed in the previous commit.
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Scala's runtime reflection works in few modes. The primary mode reads
reads out the pickled signatures from ScalaSig annotations, if
avaialable. However, these aren't available for Java-defined classes
(obviously) nor for local Scala-defined classes (less obviously.),
and the Scala `Symbol`s and `Types` must be reconstructed from
the Java generic reflection metadata.
This bug occurs in the last case, and is centered in
`FromJavaClassCompleter`.
In that completer, member fields and methods are given an owner
based on the STATIC modifier. That makes sense for Java defined
classes. I'm not 100% if it makes sense for Scala defined classes;
maybe we should just skip them entirely?
This patch still includes them, but makes the ownership-assignment
more robust in the face of STATIC members emitted by the Scala
compiler backend, such as the cache fields for structural calls.
(It's reflection all the way down!). We might not have a companion
module at all, so before we ended up owning those by `NoSymbol`,
and before too long hit the dreaded NSDHNAO crash.
That crash doesn't exist any more on 2.11 (it is demoted to a
-Xdev warning), but this patch still makes sense on that branch.
This commit makes `followStatic` and `enter` more robust when
finding a suitable owner for static members. I've also factored
out the duplicated logic between the two.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.
However, since such macros are on the intersection of a number of language
features, as usual, there are bugs.
This commit fixes an unwanted interaction of macros defined in structural
types with the scala.language.reflectiveCalls guard. Since macro calls
aren't going to be carried to runtime, there's no need to warn about them.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We can't backport SI-7120 to 2.10.x as it changes erased signatures,
which can lead to interop problems between 2.10.3 and 2.10.4.
But, we can detect one of the nasty symptoms -- a bridge method
with the same signature as its target -- and treat that.
This commit detects duplicate bridges in the ASM (only) backend
and removes them.
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Used to enable `-Xcheckinit` (now also `-Ybackend:GenBCode`) when
compiling tests in the respective jenkins builds. This is currently
broken, as you can see in [recent build logs] [1], `-Xcheckinit` is
missing:
[partest] Scalac options are: -optimise
Adds `.flags` files for macro tests (correct range positions not
enforced) and for tests failing due to SI-8560 or SI-8562.
[1]: https://scala-webapps.epfl.ch/jenkins/view/nightlies/job/scala-nightly-checkinit/2058/consoleFull
|
| |\ \
| | |
| | | |
SI-7992 Fix super-accessor generation after a local class
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The transformer in the superaccessors phase uses the var
`validCurrentOwner` to track whether we're in a part of the
code that won't end up in the host method, and as such, will
need to access super-method via a super-accessor.
But, this bit of bookkeeping was not correctly reset after traversing
out of a local class. A `VerifyError` ensued.
This commit changes `atOwner` to save and restore that flag, rather
than leaving it set to `true`.
I've also added a test variation using a by-name argument.
|
| |\ \ \
| | | |
| | | | |
SI-8437 macro runtime now also picks inherited macro implementations
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously it didn't matter much that we used Class.getDeclaredMethods
instead of just getMethods, but with the introduction of macro bundles
it can make a difference which is fixed in this commit.
I'd also like to note that the fact that getMethods only returns public
methods and getDeclaredMethods also sees private methods, doesn't make
a difference, because macro implementations must be public.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I just realized that our tag-based shortcuts were incomplete, because
they only work with root mirrors (doing just u.typeTag[T].tpe means that
the type is going to be resolved in u.rootMirror because that's the default).
This commit fixes this oversight. I'm hoping for 2.11.0-RC3, but also feel
free to reschedule to 2.12.0-M1 if it becomes clear that RC3 isn't happening.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Regressed in e3ddb2d7, which introduced `ConcatIterator` to
avoid super-linear runtime on chains of concatenated iterators.
`ConcatIterator` maintains a queue of thunks for the remaining
iterators. Both `next` and `hasNext` delegate to `advance`, which
evaluates the thunks and discards any empty iterators from the
start of the queue. The first non-empty iterator is stored in
the var `current`.
It also overrides `++`, and creates a new `ConcatIterator` with
the given `that` as an extra element in the queue. However, it
failed to copy `current` across, which led to data loss.
|
| |\ \ \
| | | |
| | | | |
SI-8425 don't create double-dollar names in c.freshName
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If we append a dollar to a user-provided prefix that ends in a dollar,
we create a potential for confusion for backend phases. That's why
this commit prevents such situations from happening.
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-4492 More informative error when class not found on classpath
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Position the error based on Select tree that failed to type check,
presumably due to an underlying MissingRequirementError, which has no position.
There are lots of other ways we could rewrap a MRE and supplement position info,
but that remains TODO. Jason's review comment is recorded in the code.
Also try to detect the case of a missing module and provide some advice,
as well as linking to the forthcoming 2.11 guide at
http://docs.scala-lang.org/overviews/core/scala-2.11.html.
|
| |\ \ \
| | | |
| | | | |
SI-8266 Amend advice for deprecated octal 042
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Improve the advice for `f"\042"` to read:
```
use ${'"'} or a triple-quoted literal """with embedded " or \u0022""" instead.
```
as per the discussion on SI-6476.
Knuth says that Charles XII came close to introducing octal arithmetic to Sweden,
and Wikipedia doesn't deny it.
I imagine an alternative history in which octal literals are deprecated in Scala
but required by legislation in Akka. #octal-fan-fiction
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
This commit ensures that the classes we use to test HashMaps and
HashSets in t6196 and t6200 have proper equals and hashCode
methods. (The old equals method returned always true and therefore
hashCode violated its contract).
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Regressed in https://github.com/scala/scala/pull/2848. In particular,
see 0cf47bdb5b and 017460e63c.
Because of the regression, this pattern:
(s @ (_s @ (_: String)))
was translated into `typeTestStep`, rather than a `bindingStep`. This
came down the the use of `unbind` in the `TypeBound` extractor.
My first step was to remove the `unbind`. That led to another
problem: the tree now matches `SymbolAndTypeBound`, which extracted
`symbol = s, tpe = String`, ignoring the `_s`. I changed that
extractor to no longer recursively apply to the sub-pattern tree,
which is what `MaybeTypedBound` used to do.
I also checked for other uses of `unbind` in the match translation.
The only place I found it is in `BoundTree#pt`. I believe that this
usage is correct, or at least, not obviously incorrect.
|
| |/ /
| |
| |
| | |
this is some weird stuff
|
| |\ \
| | |
| | | |
SI-8197 clarify overloading resolution with default args
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit was co-authored with Lukas. His analysis is below.
If there are multiple applicable alternatives, drop those
that use default arguments. This is done indirectly by
checking applicability based on arity.
TODO: this `namesMatch` business is not spec'ed, and is
the wrong fix for SI-4592. We should instead clarify what
the spec means by "typing each argument with an undefined expected type".
What does typing a named argument entail when we don't know what
the valid parameter names are? (Since we're doing overload resolution,
there are multiple alternatives that can define different names.)
Luckily, the next step checks applicability to the individual alternatives,
so it knows whether an assignment is:
- a valid named argument
- a well-typed assignment (which doesn't necessarily have type `Unit`!)
- an error (e.g., rhs does not refer to a variable)
I propose the following solution (as a TODO):
check whether a named argument (when typing it in `doTypedApply`)
could be interpreted as an assign; `infer.checkNames` should use
the type of the well-typed assignment instead of `Unit`.
Lukas's analysis:
990fa04 misunderstood the spec of overloading resolution with
defaults. it should not discard applicable alternatives that define
defaults, but only those that use defaults in the given invocation.
bugs were shadowed because the refactoring used `alt.hasDefault` to
check whether the alternative has some parameters with defaults, but
this never worked.
d5bb19f fixed that part by checking the flags of parameters, which
fixed some but but un-shadowed others:
```
object t { def f(x: String = "") = 1; def f(x: Object) = 2 }
scala> t.f("") // should return 1, but returns 2 after d5bb19f
```
The commit message of d5bb19f also mentions that its test "should
fail to compile according to SI-4728", which is another
misunderstanding.
```
class A; class B extends A
object t { def f(x: A = null) = 1; def f(x: B*) = 2 }
t.f()
```
This should return `2`: both alternatives are applicable, so the one
that uses a default is eliminated, and we're left with the vararg one.
SI-4728 is different in that it uses explicit parameters,
`t.f(new B)` is ambiguous.
|
| |\ \ \
| | | |
| | | | |
SI-3235 math.round() returns wrong results for Int and Long
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Minimal fix for SI-3235.
This minimal fix includes deprecation messages to aid detection of probable errors.
Test verifies behavior: the correct values are returned, and deprecation messages are emitted.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the first step towards fixing the unexpected behavior of `ListBuffer`.
Many of `ListBuffer`'s operations are forwarded to the underlying `List`,
essentially leaking that abstraction to clients that call e.g., `toIterable`.
When the buffer changes, the `Iterable` obtained through `toIterable` will
reflect that change.
To avoid this exposure, call `toList` to obtain an immutable copy.
See also:
https://groups.google.com/d/msg/scala-internals/g_-gIWgB8Os/kWazrALbLKEJ
https://gist.github.com/paulp/9081797
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The SI-8233 / 9506d52 missed one case when we need to DROP a null from
a stack: when unboxed Unit is an expected type. If we forgot to do that
in a context where two branches were involved we could end up with
unbalanced stack sizes.
Let's fix that omission and a test covering that specific case to the
original test for SI-8233.
Fixes SI-8330.
|
| |\ \
| | |
| | | |
SI-1503 don't assume unsound type for ident/literal patterns
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The fix only kicks in under -Xfuture. We also warn under -Xlint.
What type should a variable bound to the value matched by a pattern have?
To avoid CCEs, it should be a type that's implied by the matching
semantics of the pattern.
Usually, the type implied by a pattern matching a certain value
is the pattern's type, because pattern matching implies instance-of checks.
However, Stable Identifier and Literal patterns are matched using `==`,
which does not imply a type for the binder that binds the matched value.
The change in type checking due to this fix is that programs that used to crash with a CCE
(because we blindly cast to the type of the pattern, which a `==` check does not imply)
now get a weaker type instead (and no cast). They may still type check, or they may not.
To compensate for this fix, change `case x@Foo => x` to `case x: Foo.type => x`,
if it's important that `x` have type `Foo.type`.
See also:
- SI-4577: matching of singleton type patterns uses `eq`,
not `==` (so that the types are not a lie).
- SI-5024: patmat strips unused bindings, but affects semantics
|
| |\ \ \
| | | |
| | | | |
SI-8321 bundles can't be whitebox
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Given the recent glaring oversight in macro bundles, I have to have more
tests in order to make sure that things are going to work as they should.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
whitebox.Context <: blackbox.Context, so in order to check for blackboxity
it's not enough to check whether the context used is <: blackbox.Context.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8197 Only consider immediate params for defaults, overloading
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A recent commit fixed the behaviour of overloading with regards
to discarding candiates that include default arguments. The old
check was checking the wrong flag.
But, the new code is actually checking all parameter lists for
defaults, which led to a regression in scala-io, which is distilled
in the enclosed test case. Applications are typechecked one
parameter list at a time, so a holistic check for defaults doesn't
seem to make sense; only defaults in the first parameter list
ought to count.
|
| |\ \ \ \
| |/ / /
|/| | | |
SI-5479 deprecate DelayedInit outside of App
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
DelayedInit's semantics are way too surprising.
For example, it delays initialization of fields,
so that fields on objects that extend `App`
(which `extends DelayedInit`) are not initialized
until the `main` method is called.
For more details and a proposed alternative,
see https://issues.scala-lang.org/browse/SI-4330?jql=labels%20%3D%20delayedinit%20AND%20resolution%20%3D%20unresolved.
Support for `App` will continue -- we'll special case it.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8197 Overload resolution should not consider default arguments
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The spec says
> Let B be the set of alternatives in A that are applicable (§6.6)
> [...] It is an error if none of the members in B is applicable. If
> there is one single applicable alternative, that alternative is
> chosen. Otherwise, let C be the set of applicable alternatives which
> don’t employ any default argument in the application to e1, ..., em.
> It is again an error if C is empty. Otherwise, one chooses the most
> specific alternative among the alternatives in C [...].
There are many ways to interpret this, but none of them involves
excluding default getters, which is what the old code was doing.
We now exclude all alternatives that define any default arguments.
NOTE: according to SI-4728, this should fail to compile with an
ambiguity error. The compiler has been accepting this program
for all of 2.10.x, as far as I can tell, so let's not change that
for 2.11.0-RC1...
|
