| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Typechecking a pattern that defines a pattern type variable
initially assigns abstract type symbol with open type bounds.
Later on, pattern type inference kicks in to sharpen the type
of the variable based on constraints imposed by the expected
type (ie, the type of scrutinee of the pattern.)
However, before inference does this, a `TypeRef` to the abstract
type symbol can be queried for its base type with respect to some
class, which leads to it populating an internal cache. This cache
becomes stale when the underlying symbol has its type mutated.
The repercussions of this meant that a subsequent call to `baseType`
gave the wrong result (`NoType`), which lead to an `asSeenFrom`
operation to miss out of substitution of a type variable. Note the
appearance of `A` in the old type errors in the enclosed test case.
This commit takes an approach similar to 286dafbd to invalidate
caches after the mutation. I've routed both bandaids through the
same first aid kit: I'm sure over time we'll add additional calls
to this method, and additional cache invalidations within it.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
partest has custom code for -Xplugin handling (see
DirectCompiler.updatePluginPath for details). that code has its own
idea of what the syntax of -Xplugin is, different from Scalac's.
partest's idea is that multiple paths should be separated by the
platform classpath separator character, so : on Unix and ; on Windows.
the .flags file here was using a colon, and that confuses partest on
Windows, since partest was expecting a semicolon.
it might be nice to fix partest to accept comma as the separator
instead, which is standard for a scalac MultiStringSetting such
as -Xplugin. but it turns out we have an out: we can just provide
multiple -Xplugin flags.
what evidence do I have that this is the right change?
* the test still passes on both Windows and Mac OS X (manually
tested); if Travis likes it, we'll know it passes on Linux too
* I tried reverting Som's fix for SI-9370 (c32ba93) and the test failed,
as expected, both with and without my change
* I added a bunch of debugging output to
DirectCompiler.updatePluginPath in partest, built a new partest jar,
and used it to run the test on Windows with and without my fix, and
verified by eye that the logic there was operating as expected in
both cases
and in conclusion, for Som's benefit: <insert cryptic joke here>
|
| |
| |
| |
| | |
Such that uncurry can correctly un-dependify them.
|
| |\
| | |
| | | |
unset inappropriate execute bits
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I imagine these date back to old Subversion days and are probably the
result of inadvertent commits from Windows users with vcs client
configs.
having the bit set isn't really harmful most of the time,
but it's just not right, and it makes the files stand out in directory
listings for no reason
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A previous optimization (d44a86f432a7f9ca250b014acdeab02ac9f2c304) for
pattern matcher exhaustivity checks used a smarter encoding to ensure
that the scrutinee can be equal to one child only.
However, in case of traits between the root and leave type, a child can
be of several types and these types should not be in a mutually exclusive
group. A simple solution (hat tip to retronym) is to just put traits
and classes into separate groups.
|
| |\ \
| | |/
| |/| |
SI-9442 Fix the uncurry-erasure types
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Using the "uncurry-erased" type (the one after the uncurry phase) can
lead to incorrect tree transformations. For example, compiling:
```
def foo(c: Ctx)(l: c.Tree): Unit = {
val l2: c.Tree = l
}
```
Results in the following AST:
```
def foo(c: Ctx, l: Ctx#Tree): Unit = {
val l$1: Ctx#Tree = l.asInstanceOf[Ctx#Tree]
val l2: c.Tree = l$1 // no, not really, it's not.
}
```
Of course, this is incorrect, since `l$1` has type `Ctx#Tree`, which is
not a subtype of `c.Tree`.
So what we need to do is to use the pre-uncurry type when creating
`l$1`, which is `c.Tree` and is correct. Now, there are two
additional problems:
1. when varargs and byname params are involved, the uncurry
transformation desugares these special cases to actual
typerefs, eg:
```
T* ~> Seq[T] (Scala-defined varargs)
T* ~> Array[T] (Java-defined varargs)
=>T ~> Function0[T] (by name params)
```
we use the DesugaredParameterType object (defined in
scala.reflect.internal.transform.UnCurry) to redo this desugaring
manually here
2. the type needs to be normalized, since `gen.mkCast` checks this
(no HK here, just aliases have to be expanded before handing the
type to `gen.mkAttributedCast`, which calls `gen.mkCast`)
|
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Scala classfile and java source parsers make Java annotation
classes (which are actually interfaces at the classfile level) look
like Scala annotation classes:
- the INTERFACE / ABSTRACT flags are not added
- scala.annotation.Annotation is added as superclass
- scala.annotation.ClassfileAnnotation is added as interface
This makes type-checking @Annot uniform, whether it is defined in Java
or Scala.
This is a hack that leads to various bugs (SI-9393, SI-9400). Instead
the type-checking should be special-cased for Java annotations.
This commit fixes SI-9393 and a part of SI-9400, but it's still easy
to generate invalid classfiles. Restores the assertions that were
disabled in #4621. I'd like to leave these assertions in: they
are valuable and helped uncovering the issue being fixed here.
A new flag JAVA_ANNOTATION is introduced for Java annotation
ClassSymbols, similar to the existing ENUM flag. When building
ClassBTypes for Java annotations, the flags, superclass and interfaces
are recovered to represent the situation in the classfile.
Cleans up and documents the flags space in the area of "late" and
"anti" flags.
The test for SI-9393 is extended to test both the classfile and the
java source parser.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A macro in shapeless was generating a tree of the form:
```
{
class C#2
new C#2
}.setType(C#1)
```
This happened due to an error in the macro; it used untypecheck
to try to fix the owner-chain consistency problem, but kept a
reference to the previous version of the block-local class symbol
`C` and used this in the resulting tree.
This commit detects the particular situation we encountered, and
avoids the crash by not creating the `NestedInfo` for the
`BType` corresponding to `C#1`. The code comment discusses why I
think this is safe, and suggests a refactoring that would mean
we only ever try to construct `NestedInfo` when we are going to
need them.
|
| |
| |
| |
| |
| |
| | |
These cause a crash in the build of Play. We should try to bring
these back once we have suitable annotation awareness. Perhaps
they should only be `devWarning`-s, though.
|
|\ \
| | |
| | | |
Inliner heuristic for higher-order methods
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
The new optimizer doesn't have this problem.
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One shouldn't base any decisions of the owner of an overloaded
symbol. Instead, the owner of each of the alternatives should
be considered.
This gotcha is super easy to forget, as I did with my change to
simplify the way we detect whether we need to add the `.package`
prefix to a tree.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
only trivial merge conflicts here.
not dealing with PR #4333 in this merge because there is a substantial
conflict there -- so that's why I stopped at
63daba33ae99471175e9d7b20792324615f5999b for now
|
|\ \ \
| |/ /
|/| | |
SI-9375 add synthetic readResolve only for static modules
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For inner modules, the synthetic readResolve method would cause the
module constructor to be invoked on de-serialization in certain
situations. See the discussion in the ticket.
Adds a comprehensive test around serializing and de-serializing
modules.
|
|\ \ \
| |/ /
|/| | |
SI-9393 fix modifiers of ClassBTypes for Java annotations
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Scala classfile and java source parsers make Java annotation
classes (which are actually interfaces at the classfile level) look
like Scala annotation classes:
- the INTERFACE / ABSTRACT flags are not added
- scala.annotation.Annotation is added as superclass
- scala.annotation.ClassfileAnnotation is added as interface
This makes type-checking @Annot uniform, whether it is defined in Java
or Scala.
This is a hack that leads to various bugs (SI-9393, SI-9400). Instead
the type-checking should be special-cased for Java annotations.
This commit fixes SI-9393 and a part of SI-9400, but it's still easy
to generate invalid classfiles. Restores the assertions that were
disabled in #4621. I'd like to leave these assertions in: they
are valuable and helped uncovering the issue being fixed here.
A new flag JAVA_ANNOTATION is introduced for Java annotation
ClassSymbols, similar to the existing ENUM flag. When building
ClassBTypes for Java annotations, the flags, superclass and interfaces
are recovered to represent the situation in the classfile.
Cleans up and documents the flags space in the area of "late" and
"anti" flags.
The test for SI-9393 is extended to test both the classfile and the
java source parser.
|
|\ \ \
| |/ /
|/| /
| |/ |
merge/2.11.x-to-2.12.x-20152307
|
| |\
| | |
| | | |
Fix 23 typos (t-v)
|
| | | |
|
| |\ \
| | |/
| |/| |
SI-9370 Xplugin scans plugin path for descriptor
|
| | |
| | |
| | |
| | |
| | | |
Keep on scanning if the first entry doesn't yield
a plugin.xml descriptor.
|
|\ \ \
| | | |
| | | | |
SI-9392 Avoid crash in GenBCode for incoherent trees
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A macro in shapeless was generating a tree of the form:
```
{
class C#2
new C#2
}.setType(C#1)
```
This happened due to an error in the macro; it used untypecheck
to try to fix the owner-chain consistency problem, but kept a
reference to the previous version of the block-local class symbol
`C` and used this in the resulting tree.
This commit detects the particular situation we encountered, and
avoids the crash by not creating the `NestedInfo` for the
`BType` corresponding to `C#1`. The code comment discusses why I
think this is safe, and suggests a refactoring that would mean
we only ever try to construct `NestedInfo` when we are going to
need them.
|
|\ \ \ \
| | | | |
| | | | | |
Merge 2.11.x to 2.12.x [ci: last-only]
|
| |\ \ \ \
| | |/ / /
| |/| / /
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
merge/2.11.x-to-2.12.x-20150713
Conflicts:
src/eclipse/partest/.classpath
src/eclipse/repl/.classpath
test/files/run/nothingTypeNoFramesNoDce.scala
test/files/run/repl-javap-app.check
Also fixup two .classpath files with updated partest, xml and
parser combinators JARs.
|
| | | | |
|
| | |/ |
|
|\ \ \
| | | |
| | | | |
SI-9393 Temporarily disable two assertions in GenBCode
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
These cause a crash in the build of Play. We should try to bring
these back once we have suitable annotation awareness. Perhaps
they should only be `devWarning`-s, though.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove some unnecessary flags files
- neg/t4425.flags
- run/blame_eye_triple_eee-double.flags
- run/blame_eye_triple_eee-float.flags
Force tests that use -optimize to GenASM
- neg/sealed-final-neg.flags
- pos/inline-access-levels.flags
- pos/inliner2.flags
- pos/sealed-final.flags
- pos/t3420.flags
- pos/t8410.flags
- run/constant-optimization.flags
- run/dead-code-elimination.flags
- run/elidable-opt.flags
- run/finalvar.flags
- run/icode-reader-dead-code.scala
- run/optimizer-array-load.flags
- run/synchronized.flags
- run/t3509.flags
- run/t3569.flags
- run/t4285.flags
- run/t4935.flags
- run/t5789.scala
- run/t6188.flags
- run/t7459b-optimize.flags
- run/t7582.flags
- run/t7582b.flags
- run/t8601.flags
- run/t8601b.flags
- run/t8601c.flags
- run/t8601d.flags
- run/t8601e.flags
- run/t9003.flags
Move some tests to the new optimizer
- run/classfile-format-51.scala
- run/classfile-format-52.scala
- run/run-bug4840.flags
- run/t2106.flags
- run/t6102.flags
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
I just used text search to check whether there are no more typos like
these corrected by janekdb, and by the way fixed also some other ones
which I saw.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Calling `exists` on a `Symbol` triggers unpickling,
which failed for reasons I did not investigate.
Replaced `sym.exists` by `sym != NoSymbol`, which is good enough here.
Also replaced assertion by a `devWarning`, since the
logic seems too ad-hoc to actually crash the compiler when it's invalidated.
Partially reverts b45a91fe22. See also #1532.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I checked the intent with Martin, who said:
> [...] qualified private members are inherited like other members,
> it’s just that their access is restricted.
I've locked this in with a test as well.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The typechecker rewrites `p.foo` to `p.<package>.foo` if `foo`
must come from a package object. This logic was overhauled in
51745c06f3, but this caused a regression.
I reverted to the predecessor of that commit to see how things
worked before. The lookup of the name `X` bound to the existential
quantifier, but incorrectly included the prefix `test.type` in the
result of the lookup. However, the subsequent call to
`isInPackageObject` (from `makeAccessible`) returned false, so
we didn't try to rewrite `X` to `test.<package>.X`.
This commit makes a minimal fix that makes `isInPackageObject`
return false for existentials.
|
|\| |
|
| |\
| | |
| | | |
SI-9285 Don't warn about non-sensible equals in synthetic methods
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Notably, in the synthetic equals method of a case class. Otherwise,
we get an unsuppressable warning when defining a case class with a
`Unit`-typed parameter, which some folks use a placeholder for
real type while evolving a design.
|
| |/ |
|
|\|
| |
| |
| | |
merge/2.11.x-to-2.12.x-20150501
|
| |
| |
| |
| |
| | |
This commit corrects many typos found in scaladocs and comments.
There's also fixed the name of a private method in ICodeCheckers.
|