| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also make this whole retraction of apply/unapply in case of a
clashing user-defined member conditional on `-Xsource:2.12`.
It turns out, as explained by lrytz, that the retraction mechanism
was fragile because it relied on the order in which completers are run.
We now cover both the case that:
- the completer was run, the `IS_ERROR` flag was set, and the
symbol was unlinked from its scope before `addSynthetics`
in `typedStat` iterates over the scope (since the symbol is
already unlinked, the tree is not added, irrespective of its flags).
For this case, we also remove the symbol from the synthetics in
its unit (for cleanliness).
- the completer is triggered during the iteration in `addSynthetics`,
which needs the check for the `IS_ERROR` flag during the iteration.
Before, the completer just unlinked the symbol and set the IS_ERROR flag,
and I assumed the typer dropped a synthetic tree with a symbol with
that flag, because the tree was not shown in -Xprint output.
In reality, the completer just always happened to run before the
addSynthetics loop and unlinked the symbol from its scope in the
test cases I came up with (including the 2.11 community build).
Thankfully, the 2.12 community build caught my mistake, and lrytz provided
a good analysis and review.
Fix scala/bug#10261
|
| | |
|
| |
|
|
| |
Fixes the problem reported with #5730 by xuwei-k in scala/scala-dev#352.
|
| |
|
|
| |
This reverts commit eb5c51383a63c5c3420e53ef021607ff5fd20296.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we create a class symbols from a classpath elements, references
to other classes that are absent from the classpath are represented
as references to "stub symbols". This is not a fatal error; for instance
if these references are from the signature of a method that isn't called
from the program being compiled, we don't need to know anything about them.
A subsequent attempt to look at the type of a stub symbols will trigger a
compile error.
Currently, the creation of a stub symbol incurs a warning. This commit
removes that warning on the basis that it isn't something users need
to worry about. javac doesn't emit a comparable warning.
The warning is still issued under any of `-verbose` / `-Xdev` / `-Ydebug`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following commit message is a squash of several commit messages.
- This is the 1st commit message:
Add position to stub error messages
Stub errors happen when we've started the initialization of a symbol but
key information of this symbol is missing (the information cannot be
found in any entry of the classpath not sources).
When this error happens, we better have a good error message with a
position to the place where the stub error came from. This commit goes
into this direction by adding a `pos` value to `StubSymbol` and filling
it in in all the use sites (especifically `UnPickler`).
This commit also changes some tests that test stub errors-related
issues. Concretely, `t6440` is using special Partest infrastructure and
doens't pretty print the position, while `t5148` which uses the
conventional infrastructure does. Hence the difference in the changes
for both tests.
- This is the commit message #2:
Add partest infrastructure to test stub errors
`StubErrorMessageTest` is the friend I introduce in this commit to help
state stub errors. The strategy to test them is easy and builds upon
previous concepts: we reuse `StoreReporterDirectTest` and add some
methods that will compile the code and simulate a missing classpath
entry by removing the class files from the class directory (the folder
where Scalac compiles to).
This first iteration allow us to programmatically check that stub errors
are emitted under certain conditions.
- This is the commit message #3:
Improve contents of stub error message
This commit does three things:
* Keep track of completing symbol while unpickling
First, it removes the previous `symbolOnCompletion` definition to be
more restrictive/clear and use only positions, since only positions are
used to report the error (the rest of the information comes from the
context of the `UnPickler`).
Second, it adds a new variable called `lazyCompletingSymbol` that is
responsible for keeping a reference to the symbol that produces the stub
error. This symbol will usually (always?) come from the classpath
entries and therefore we don't have its position (that's why we keep
track of `symbolOnCompletion` as well). This is the one that we have to
explicitly use in the stub error message, the culprit so to speak.
Aside from these two changes, this commit modifies the existing tests
that are affected by the change in the error message, which is more
precise now, and adds new tests for stub errors that happen in complex
inner cases and in return type of `MethodType`.
* Check that order of initialization is correct
With the changes introduced previously to keep track of position of
symbols coming from source files, we may ask ourselves: is this going to
work always? What happens if two symbols the initialization of two
symbols is intermingled and the stub error message gets the wrong
position?
This commit adds a test case and modifications to the test
infrastructure to double check empirically that this does not happen.
Usually, this interaction in symbol initialization won't happen because
the `UnPickler` will lazily load all the buckets necessary for a symbol
to be truly initialized, with the pertinent addresses from which this
information has to be deserialized. This ensures that this operation is
atomic and no other symbol initialization can happen in the meantime.
Even though the previous paragraph is the feeling I got from reading the
sources, this commit creates a test to double-check it. My attempt to be
better safe than sorry.
* Improve contents of the stub error message
This commit modifies the format of the previous stub error message by
being more precise in its formulation. It follows the structured format:
```
s"""|Symbol '${name.nameKind} ${owner.fullName}.$name' is missing from the classpath.
|This symbol is required by '${lazyCompletingSymbol.kindString} ${lazyCompletingSymbol.fullName}'.
```
This format has the advantage that is more readable and explicit on
what's happening. First, we report what is missing. Then, why it was
required. Hopefully, people working on direct dependencies will find the
new message friendlier.
Having a good test suite to check the previously added code is
important. This commit checks that stub errors happen in presence of
well-known and widely used Scala features. These include:
* Higher kinded types.
* Type definitions.
* Inheritance and subclasses.
* Typeclasses and implicits.
- This is the commit message #4:
Use `lastTreeToTyper` to get better positions
The previous strategy to get the last user-defined position for knowing
what was the root cause (the trigger) of stub errors relied on
instrumenting `def info`.
This instrumentation, while easy to implement, is inefficient since we
register the positions for symbols that are already completed.
However, we cannot do it only for uncompleted symbols (!hasCompleteInfo)
because the positions won't be correct anymore -- definitions using stub
symbols (val b = new B) are for the compiler completed, but their use
throws stub errors. This means that if we initialize symbols between a
definition and its use, we'll use their positions instead of the
position of `b`.
To work around this we use `lastTreeToTyper`. We assume that stub errors
will be thrown by Typer at soonest.
The benefit of this approach is better error messages. The positions
used in them are now as concrete as possible since they point to the
exact tree that **uses** a symbol, instead of the one that **defines**
it. Have a look at `StubErrorComplexInnerClass` for an example.
This commit removes the previous infrastructure and replaces it by the
new one. It also removes the fields positions from the subclasses of
`StubSymbol`s.
- This is the commit message #5:
Keep track of completing symbols
Make sure that cycles don't happen by keeping track of all the
symbols that are being completed by `completeInternal`. Stub errors only
need the last completing symbols, but the whole stack of symbols may
be useful to reporting other error like cyclic initialization issues.
I've added this per Jason's suggestion. I've implemented with a list
because `remove` in an array buffer is linear. Array was not an option
because I would need to resize it myself. I think that even though list
is not as efficient memory-wise, it probably doesn't matter since the
stack will usually be small.
- This is the commit message #6:
Remove `isPackage` from `newStubSymbol`
Remove `isPackage` since in 2.12.x its value is not used.
|
| |\
| |
| | |
SI-10206 tighten fix for SI-6889
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implicit search implements a restriction that the target type for an
implicit view should be more specific that AnyRef or AnyVal.
scala> def foo(s: String): AnyVal = s
<console>:12: error: the result type of an implicit conversion must be more specific than AnyVal
def foo(s: String): AnyVal = s
^
Without this, an implicit value classes over `String` would be applied,
which is unlikely to be what was intended.
Implicit views are implemented as an implicit search for a function type
with a structural type as its result. This structural type is created
with:
scala> val schema = analyzer.HasMethodMatching.apply(TermName("clone"), Nil, WildcardType)
schema: $r.intp.global.analyzer.global.Type = ?{def clone(): ?}
The quirk arises when, as above, we're seeking a member with the same name
as a member of AnyRef. AnyRef is seen to be a subtype of the result type:
scala> AnyRefClass.tpe <:< schema
res23: Boolean = true
Which leads to the implicit in the test case being disqualified. The typer
opts to report the error about the inapplicability of the inherited clone
method, so we don't even know why the implicit was discarded.
|
| | |
| |
| |
| |
| | |
There are more supertypes of `AnyRef` than you might think:
`?{def clone: ?}` is one example...
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
Don't emit a synthetic `apply` (or `unapply`) when it would
clash with an existing one. This allows e.g., a `private apply`,
along with a `case class` with a `private` constructor.
We have to retract the synthetic method in a pretty roundabout way,
as we need the other methods and the owner to be completed already.
Unless we have to complete the synthetic `apply` while completing
the user-defined one, this should not be a problem. If this does
happen, this implies there's a cycle in computing the user-defined
signature and the synthetic one, which is not allowed.
|
| |
|
|
|
| |
follows up on https://github.com/scala/scala/pull/5664;
fixes https://github.com/scala/scala-dev/issues/301
|
| | |
|
| | |
|
| |
|
|
| |
Specifically, the `slice` and `take` methods.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A Scala method that implements a generic, Java-defined
varargs method, needs two bridges:
- to convert the collections for the repeated parameters (VBRIDGE)
- to bridge the generics gap (BRIDGE)
Refchecks emits the varargs "bridges", and erasure takes care
of the other gap. Because a VBRIDGE was also an ARTIFACT,
it was wrongly considered inert with respect to erasure,
because `OverridingPairs` by default excluded artifacts.
Removed the artifact flag from those VBRIDGES, so that they
qualify for a real bridge. It would also work to include
VBRIDGE methods that are artifacts in BridgesCursor.
|
| | |
|
| |\
| |
| | |
[backport] SI-10071 SI-8786 varargs methods
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(cherry-picking commit a03e7a0)
I have repeatedly seen this fail CI runs, including recently
as the comment in the test itself says: "I'm not sure this is a great
way to test for memory leaks, since we're also testing how good
the JVM's GC is, and this is not easily reproduced between
machines/over time"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make sure that methods annotated with varargs are properly mixed-in. This commit
splits the transformation into an info transformer (that works on all symbols, whether
they come from source or binary) and a tree transformer.
The gist of this is that the symbol-creation part of the code was moved to the UnCurry
info transformer, while tree operations remained in the tree transformer. The newly
created symbol is attached to the original method so that the tree transformer can still
retrieve the symbol.
A few fall outs:
- I removed a local map that was identical to TypeParamsVarargsAttachment
- moved the said attachment to StdAttachments so it’s visible between reflect.internal
and nsc.transform
- a couple more comments in UnCurry to honour the boy-scout rule
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When generating a varargs forwarder for
def foo[T](a: T*)
the parameter type of the forwarder needs to be Array[Object]. If we
generate Array[T] in UnCurry, that would be erased to plain Object, and
the method would not be a valid varargs.
Unfortunately, setting the parameter type to Array[Object] lead to
an invalid generic signature - the generic signature should reflect the
real signature.
This change adds an attachment to the parameter symbol in the varargs
forwarder method and special-cases signature generation.
Also cleans up the code to produce the varargs forwarder. For example,
type parameter and parameter symbols in the forwarder's method type were
not clones, but the same symbols from the original method were re-used.
Backported from 0d2760dce189cdcb363e54868381175af4b2646f,
with a small tweak (checkVarargs) to make the test work on Java 6,
as well as later versions.
|
| |\ \
| | |
| | | |
SI-9114 Fix crasher in pattern matcher with type aliases
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When determining whether or not a pattern match requires an equality
check of the outer instance of a type in addition to a type test,
`needsOuterTest` determines if the intersection of the selector and
the pattern types could be populated. Both type arrive at
`isPopulated` dealised.
However, `isPopulated` recurs when it encounters an existential,
and, as seen in thest case, a failure to dealias the quantified
type can lead to an assertion failure as we try to relate a
typeref to an alias and a typeref to a class.
See also SI-7214, which added deliasing of the pattern type
before calling `isPopulated`.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Time for the courage of our convictions: follow the advice of my
TODO comment from SI-8244 / f62e280825 and fix `classExistentialType`
once and for all.
This is the change in the generated `canEquals` method in the test
case; we no longer get a kind conformance error.
```
--- sandbox/old.log 2015-05-27 14:31:27.000000000 +1000
+++ sandbox/new.log 2015-05-27 14:31:29.000000000 +1000
@@ -15,7 +15,7 @@
case _ => throw new IndexOutOfBoundsException(x$1.toString())
};
override <synthetic> def productIterator: Iterator[Any] = runtime.this.ScalaRunTime.typedProductIterator[Any](Stuff.this);
- <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[Proxy[PP]]]();
+ <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[_ <: [PP]Proxy[PP]]]();
override <synthetic> def hashCode(): Int = ScalaRunTime.this._hashCode(Stuff.this);
override <synthetic> def toString(): String = ScalaRunTime.this._toString(Stuff.this);
override <synthetic> def equals(x$1: Any): Boolean = x$1 match {
@@ -38,9 +38,3 @@
}
}
```
I also heeded my own advice to pass in a prefix to this method.
|
| |\
| |
| |
| |
| | |
monkey-mas/modify-ArrayBuilder-reusability-bug-2016-12-24
[Backport] Modify ArrayBuilder and WrappedArrayBuilder to be reusable
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As they're reusable in 2.12.x with this change[1], it'd be useful
to make them reusable in 2.11.x.
[1] https://github.com/scala/scala/commit/6eaae1b969b68ed3dc65a40613a8168b09246256
With this change, not only are they reusable but also we can avoid
mutation of previously created arrays.
Behaviour(Problem):
Actual behaviour before this modification is as follows;
<ArrayBuilder>
```
scala> import scala.collection.mutable.ArrayBuilder
import scala.collection.mutable.ArrayBuilder
scala> val builder = new ArrayBuilder.ofInt
builder: scala.collection.mutable.ArrayBuilder.ofInt = ArrayBuilder.ofInt
scala> builder ++= Vector.range(1, 17)
res0: builder.type = ArrayBuilder.ofInt
scala> val arr = builder.result()
arr: Array[Int] = Array(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
scala> builder.clear()
scala> builder += 100
res2: builder.type = ArrayBuilder.ofInt
scala> val arr2 = builder.result()
arr2: Array[Int] = Array(100)
scala> arr
res3: Array[Int] = Array(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
// arr should be Array(1, .., 16) but was unexpectedly mutated by `+=` operation
```
`arr` was mutated as follows;
1. `result` & `clear`
- `arr = elems`
- `size = 0`
2. `+=(100)`
- `ensureSize(0 + 1)`
=> `capacity < size || capacity == 0` is `false` as `capacity == 16`
and `size == 1`
- `elems(0) = 100` this is where `arr(0) = 100` was done because we
did not reallocate a new array for `elems` when calling `ensureSize`,
which should have happened.
- `size = 1`
3. `result`
- `mkArray(1)` gives us `arr2 = Array(100)`
<WrappedArrayBuilder>
We can observe almost the same mutation behaviour of ArrayBuilder.
```
scala> import scala.collection.mutable.WrappedArray
import scala.collection.mutable.WrappedArray
scala> import scala.collection.mutable.WrappedArrayBuilder
import scala.collection.mutable.WrappedArrayBuilder
scala> import scala.reflect.ClassTag
import scala.reflect.ClassTag
scala> val builder = new WrappedArrayBuilder(ClassTag.Int)
builder: scala.collection.mutable.WrappedArrayBuilder[Int] = scala.collection.mutable.WrappedArrayBuilder@56cbfb61
scala> builder ++= Vector.range(1, 17)
res0: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61
scala> builder.result()
res1: scala.collection.mutable.WrappedArray[Int] = WrappedArray(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
scala> builder.clear()
scala> builder += 100
res3: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61
scala> res1
res4: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
scala> builder.result()
res5: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100)
```
Solution:
We should reset `capacity` to `0` when calling `result` so that
`ensureSize(1)` calls `resize(16)`, which satisfies the property of Builder
reusability. Besides mutation of previously created arrays does not happen.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hash consing of trees within pattern match analysis was broken, and
considered `x1.foo#1` to be the same tree as `x1.foo#2`, even though
the two `foo`-s referred to different symbols.
The hash consing was based on `Tree#correspondsStructure`, but the
predicate in that function cannot veto correspondance, it can only
supplement the default structural comparison.
I've instead created a custom tree comparison method for use in
the pattern matcher that handles the tree shapes that we use.
(cherry picked from commit 79a52e6807d2797dee12bab1730765441a0e222d)
|
| |
|
|
|
| |
This allows it to work in Scala.js, which supports `ClassTag`s but
not `Manifest`s.
|
| |\
| |
| | |
SI-3236 constant types for literal final static java fields
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Since we don't parse Java expressions, fields of Java classes coming
from source files never have constant types. This prevents using
static java fields in annotation arguments in mixed compilation
This PR assigns constant types to final static java fields if the
initializer is a simple literal.
|
| |\ \
| | |
| | | |
SI-9834 Improve error on failed op=
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If rewriting `x += y` fails to typecheck, emit error messages
for both the original tree and the assignment.
If rewrite is not attempted because `x` is a val, then say so.
The error message at `tree.pos` is updated with the additional advice.
SI-8763 Crash in update conversion
When there are already errors, don't attempt mechanical rewrites.
|
| | | |
| | |
| | | |
SI-10086 NumericRange.min|max with custom Integral
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code used to fuzzily match, e.g, `declasses` with `getDeclaredClasses`
was exploring fruitless parts of the search space. The enclosed test
case was hanging the REPL.
This commit improves this by performing a prefix match of the unconsumed input
against the current chunk of the candidate before exploring the `inits`.
Fixes scala/scala-dev#271
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Noticed when inlining from a class file.
The test doesn't work because inlining fails with
bytecode unavailable due to:
```
scala.reflect.internal.MissingRequirementError: object X in compiler mirror not found.
```
|
| |\ \
| |/
|/| |
[backport] Replace println with log calls in BrowsingLoaders
|
| | |
| |
| |
| |
| |
| |
| | |
This alternative symbol loader is used in the presentation compiler and
may generate output even when the compiler should be silent.
See SI-8717 for more context, even though this does not really
fix the ticket.
|
| |\ \
| |/
|/| |
SI-9913 Lead span iterator finishes at state -1
|
| | |
| |
| |
| |
| | |
Even if no elements fail the predicate (so that the trailing
iterator is empty).
|
| |\ \
| | |
| | | |
SI-9832 Fix line endings in junit test
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
SI-2712 Add support for higher order unification
|
| | | |/
| |/| |
|
| |\ \ \
| | |/
| |/| |
SI-9832 -Xlint:help shows default
|
| | |/
| |
| |
| |
| |
| | |
Conclude help method with the default list.
Extra words are supplied for underscore.
|
| |\ \
| | |
| | | |
[nomerge] Partial fix for SI-7046
|
| | |/ |
|
