| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\
| |
| | |
SI-6455 no longer rewrite .withFilter to .filter
|
| | |
| |
| |
| |
| | |
This has been deprecated for two major releases now,
but `filter`'s still preferred over `withFilter` in the wild.
|
| |\ \
| | |
| | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
At the moment, bundle selection mechanism is pretty picky. If a candidate
bundle's parameter isn't either blackbox.Context, whitebox.Context or
PrefixType refinement thereof, then it's not a bundle and the user
will get a generic error.
However we can be a bit more helpful and admit classes that are almost
like bundles (looksLikeMacroBundleType), have them fail isMacroBundleType,
and then emit a much prettier error message to the user that would tell them
that bundles must be monomorphic and their sole parameter should not just
be any subtype of blackbox.Context or whitebox.Context.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's not like they were inducing bugs, but I can't see how polymorphism
can be useful for macro bundles, hence imho it's better to reduce the
number of degrees of freedom of the system.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Vanilla macros only allow blackbox.Context, whitebox.Context and
PrefixType refinements thereof. Bundles should behave in the same way.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
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-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.
|
| |\ \ \
| | | |
| | | | |
Small Predef cleanup
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To support the established pattern for disabling it for
an compilation unit.
Update scaladoc's knowledge of our "typeclasses".
Leave a `private[scala]` version of `StringAdd` (public in bytecode)
to ensure binary compatibility with 2.11.0-M8 for partest.
|
| |\ \ \
| | | |
| | | | |
SI-6675 deprecation warning for auto-tupling in patterns
|
| | | |/
| |/|
| | |
| | |
| | | |
NOTE: when the deprecation warning becomes an error,
SI-6111 must become a `won't fix`
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Rename cardinality into rank. Shorter word, easier to
understand, more appropriate in our context.
2. Previously we called any dollar substitution splicing
but this is not consistent with Scheme where splicing
is substitution with non-zero rank.
So now $foo is unquoting and ..$foo and ...$foo is
unquote splicing or just splicing. Correspondingly
splicee becomes unquotee.
3. Rename si7980 test into t7980
|
| |\ \
| |/
|/| |
SI-8063 and its seventy friends
|
| | |
| |
| |
| |
| |
| | |
Highlights the dilemma with rich type members in the cake that no longer
exists. One used to have to choose between overloading or patmat/extmeth
friendliness, but couldn't have both. Thanks to retronym we can have it all.
|
| | |\ |
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/compiler/scala/reflect/macros/compiler/Resolvers.scala
src/compiler/scala/reflect/macros/contexts/Typers.scala
src/compiler/scala/tools/reflect/ToolBoxFactory.scala
src/reflect/scala/reflect/api/BuildUtils.scala
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
| | |\ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I have finally overcome my fear of positions and got to cleaning up its
public interface.
Apparently it isn’t so bad, since there’s a sane core of methods (thanks
to whoever wrote the comments to internal#Position):
1) Checks to distinguish offsets, opaque ranges and transparent ranges
2) Essentials that inclide start, point, end and source
3) Factories that create new positions based on existing ones
It looks like methods from the 3rd group are exactly what we’ve been looking
for in SI-6931, so we have nothing to add in this commit.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Continuing in the direction set by the parent commit, this commit
rephrases some more usages of `local` in names and comments in typer.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Pretty much everything seems like it's intended for internal use, so I moved it to a package-private object.
Split toParArray out and put it in an implicit class. Added ability to .toParArray from Array and String also.
Added test to verify implicits are gone.
|
| | |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Experience building open source projects like Specs that use
`-Xlint` suggests that this warning is too noisy to lump in
with the others.
We are lacking in more fine-grained control of these things, so
simply turning of `-Xlint` in favour of its underlying `-Y` options
ends up *losing* some other important warnings that are predicated
directly on `-Xlint`.
Furthermore, bug reports against M8, SI-7707 SI-7712, show that
unused private/local warnings, while far less noisy, are still
in need of polish.
This commit moves these warnings to a pair of new -Y options,
neither of which is part of `-Xlint`..
Let's ask people to opt in for 2.11, and as it stabilizes, we can
consider adding it to Xlint (or the desirable evolution of that)
in the next release.
|
| | |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d.
That commit lead to an error compiling Specs2:
[info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import
[info] [warn] import DiffShortener._
[info] [warn] ^
[info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion:
[info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition
[info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126)
[info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25)
[info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
|
| |\ \ \
| | | |
| | | | |
SI-5920 enables default and named args in macros
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When producing an initial spec for macros two years ago, we sort of glossed
over named/default arguments in macro applications, leaving them for future work.
Once the aforementioned future has come, I’ve made several attempts at
making things operational (e.g. last summer), but it’s always been unclear
how to marry the quite complex desugaring that tryNamesDefaults performs
with the expectations of macro programmers to see unsugared trees
in macro impl parameters.
Here’s the list of problems that arise when trying to encode named/default
arguments of macro applications:
1) When inside macro impls we don’t really care about synthetic vals
that are typically introduced to preserve evaluation order in non-positional
method applications. When we inline those synthetics, we lose information
about evaluation order, which is something that we wouldn’t like to lose
in the general case.
2) More importantly, it’s also not very exciting to see invocations of
default getters that stand for unspecified default arguments. Ideally,
we would like to provide macro programmers with right-hand sides of those
default getters, but that is: a) impossible in the current implementation
of default parameters, b) would anyway bring scoping problems that we’re
not ready to deal with just yet.
Being constantly unhappy with potential solutions to the aforementioned
problems, I’ve been unable to nail this down until the last weekend,
when I realized that: 1) even though we can’t express potential twists in
evaluation order within linearly ordered macro impl params, we can use
c.macroApplication to store all the named arguments we want, 2) even though
we can’t get exactly what we want for default arguments, we can represent
them with EmptyTree’s, which is not ideal, but pretty workable. That’s
what has been put into life in this commit.
As a pleasant side-effect, now the macro engine doesn’t have to reinvent
the wheel wrt reporting errors about insufficient arg or arglist count.
Since this logic is intertwined with the tryNamesDefaults desugaring,
we previously couldn’t make use of it and had to roll our own logic
that checked that the number of arguments and parameters of macro applications
correspond to each other. Now it’s all deduplicated and consistent.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8270 unconfuses bundles and vanilla macros
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes a mistake in macro impl ref typechecking that used to have
an heuristic to figure out whether it looks at a bundle method ref or at
a vanilla object method ref. Under some circumstances the heuristic could
fail, and then the macro engine would reject perfectly good macro impls.
Now every macro impl ref is typechecked twice - once as a bundle method ref
and once as a vanilla object method ref. Results are then analyzed,
checked against ambiguities (which are now correctly reported instead
of incorrectly prioritizing towards bundles) and delivered to the macro
engine.
The only heuristic left in place is the one that's used to report errors.
If both bundle and vanilla typechecks fail, then if a bundle candidate
looks sufficiently similar to a bundle, a bundle typecheck error is reported
providing some common bundle definition hints.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-3452 Correct Java generic signatures for mixins, static forwarders
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[Parts of this patch and some of the commentary are from @paulp]
This took me so long to figure out I can't even tell you. Partly because
there were two different bugs, one which only arose for trait forwarders
and one for mirror class forwarders, and every time I'd make one set
of tests work another set would start failing. The runtime failures
associated with these bugs were fairly well hidden because you usually
have to go through java to encounter them: scala doesn't pay that much
attention to generic signatures, so they can be wrong and scala might still
generate correct code. But java is not so lucky.
Bug #1)
During mixin composition, classes which extend traits receive forwarders
to the implementations. An attempt was made to give these the correct
info (in method "cloneBeforeErasure") but it was prone to giving
the wrong answer, because: the key attribute which the forwarder
must capture is what the underlying method will erase to *where the
implementation is*, not how it appears to the class which contains it.
That means the signature of the forwarder must be no more precise than
the signature of the inherited implementation unless additional measures
will be taken.
This subtle difference will put on an unsubtle show for you in test
run/t3452.scala.
trait C[T]
trait Search[M] { def search(input: M): C[Int] = null }
object StringSearch extends Search[String] { }
StringSearch.search("test"); // java
// java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC;
The principled thing to do here would be to create a pair of
methods in the host class: a mixin forwarder with the erased
signature `(String)C[Int]`, and a bridge method with the same
erased signature as the trait interface facet.
But, this turns out to be pretty hard to retrofit onto the
current setup of Mixin and Erasure, mostly due to the fact
that mixin happens after erasure which has already taken
care of bridging.
For a future, release, we should try to move all bridging
after mixin, and pursue this approach. But for now, what can
we do about `LinkageError`s for Java clients?
This commit simply checks if the pre-erasure method signature
that we generate for the trait forward erases identically to
that of the interface method. If so, we can be precise. If not,
we emit the erased signature as the generic signature.
Bug #2) The same principle is at work, at a different location.
During genjvm, objects without declared companion classes
are given static forwarders in the corresponding class, e.g.
object Foo { def bar = 5 }
which creates these classes (taking minor liberties):
class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 }
class Foo { static def bar = Foo$.MODULE$.bar }
In generating these, genjvm circumvented the usual process whereby one
creates a symbol and gives it an info, preferring to target the bytecode
directly. However generic signatures are calculated from symbol info
(in this case reusing the info from the module class.) Lacking even the
attempt which was being made in mixin to "clone before erasure", we
would have runtime failures of this kind:
abstract class Foo {
type T
def f(x: T): List[T] = List()
}
object Bar extends Foo { type T = String }
Bar.f(""); // java
// java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List;
Before/after this commit:
< signature f (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>;
---
> signature f (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>;
This takes the warning count for compiling collections under
`-Ycheck:jvm` from 1521 to 26.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8266 Deprecate octal escapes in f-interpolator
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also turns the f-interpolator into a migration
assistant by suggesting alternatives for the
standard escapes.
|
| | |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit includes a test for some simple existential subtyping
checks. It is exceptionally well-commented and may be helpful to
someone trying to figure out what the rules are (supposed to be)
in the future.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When determining whether member `symLo` of `tpLo`
has a stronger type than member `symHi` of `tpHi`,
should we use memberType or memberInfo?
Well, memberType transforms (using `asSeenFrom`) `sym.tpe`,
whereas memberInfo performs the same transform on `sym.info`.
For term symbols, this ends up being the same thing (`sym.tpe == sym.info`).
For type symbols, however, the `.info` of an abstract type member
is defined by its bounds, whereas its `.tpe` is a `TypeRef` to that type symbol,
so that `sym.tpe <:< sym.info`, but not the other way around.
Thus, for the strongest (correct) result,
we should use `memberType` on the low side.
On the high side, we should use the result appropriate
for the right side of the `<:<` above (`memberInfo`).
I also optimized the method a little bit by avoiding calling memberType
if the symbol on the high side isn't eligble (e.g., it's a class).
PS: I had to add a workaround to reifyType, because
we now dealias a little less eagerly, which means
a type selection on refinement class symbols makes it to reify
this broke the t8104 tests.
I also had to update the run/t6992 test, which should now test the right thing.
Tests should be commented and/or use sensible names.
What is it testing? What is the expected outcome? We should not be left guessing.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-8134 SI-5954 Fix companions in package object under separate comp.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The tests cases enclosed exhibited two failures modes under
separate compilation.
1. When a synthetic companion object for a case- or implicit-class
defined in a package object is called for,
`Namer#ensureCompanionObject` is used to check for an explicitly
defined companion before decided to create a synthetic one.
This lookup of an existing companion symbol by `companionObjectOf`
would locate a symbol backed by a class file which was in the
scope of the enclosing package class. Furthermore, because the
owner of that symbol is the package object class that has now
been noted as corresponding to a source file in the current
run, the class-file backed module symbol is *also* deemed to
be from the current run. (This logic is in `Run#compiles`.)
Thinking the companion module already existed, no synthetic
module was created, which would lead to a crash in extension
methods, which needs to add methods to it.
2. In cases when the code explicitly contains the companion pair,
we still ran into problems in the backend whereby the class-file
based and source-file based symbols for the module ended up in
the same scope (of the package class). This tripped an assertion
in `Symbol#companionModule`.
We get into these problems because of the eager manner in which
class-file based package object are opened in `openPackageModule`.
The members of the module are copied into the scope of the enclosing
package:
scala> ScalaPackage.info.member(nme.List)
res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462
scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List)
res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462
This seems to require a two-pronged defense:
1. When we attach a pre-existing symbol for a package object symbol
to the tree of its new source, unlink the "forwarder" symbols
(its decls from the enclosing
package class.
2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`,
remove static member modules from the scope of the enclosing
package object (aka `exitingFlatten(nestedModule.owner)`).
This commit also removes the warnings about defining companions
in package objects and converts those neg tests to pos (with
-Xfatal-warnings to prove they are warning free.)
Defining nested classes/objects in package objects still has
a drawback: you can't shift a class from the package to the
package object, or vice versa, in a binary compatible manner,
because of the `package$` prefix on the flattened name of
nested classes. For this reason, the `-Xlint` warning about
this remains. This issue is tracked as SI-4344.
However, if one heeds this warning and incrementatlly recompiles,
we no longer need to run into a DoubleDefinition error (which
was dressed up with a more specific diagnostic in SI-5760.)
The neg test case for that bug has been converted to a pos.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit does not close SI-5900. It only addresses a regression
in 2.11 prereleases caused by SI-7886.
The fix for SI-7886 was incomplete (as shown by the last commit)
and incorrect (as shown by the regression in pos/t5900a.scala and
the fact it ended up inferring type parameters.)
I believe that the key to fixing this problem will be unifying
the inference of case class constructor patterns and extractor
patterns.
I've explored that idea:
https://gist.github.com/retronym/7704153
https://github.com/retronym/scala/compare/ticket/5900
But didn't quite get there.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8244 Fix raw type regression under separate compilation
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In #1901, handling of raw types encountered in signatures during class
file parsing was changed to work in the same manner as
`classExistentialType`, by using
`existentialAbstraction(cls.tparms, cls.tpe_*)`
But this never creates fresh existential symbols, and just sticks
the class type parameters it `quantified`:
scala> trait T[A <: String]
defined trait T
scala> val cls = typeOf[T[_]].typeSymbol
cls = trait T#101864
scala> cls.typeParams
res0 = List(type A#101865)
scala> cls.tpe_*
res1 = T#101864[A#101865]
scala> classExistentialType(cls)
res3 = T#101864[_ <: String#7209]
scala> val ExistentialType(quantified, result) = res3
List(type A#101865)
In the enclosed test case, this class type parameter was substituted
during `typeOf[X] memberType sym`, which led us unsoundly thinking
that `Raw[_]` was `Raw[X]`.
I've added a TODO comment to review the other usages of
`classExistentialType`.
Test variations include joint and separate compilation, and the
corresponding Scala-only code. All fail with type errors now,
as we expect. I've also added a distillation of a bootstrap
error that failed when I forgot to wrap the `existentialType`.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[Most of this comment and the initial fix were implemented by Jason Zaugg.
I just cleaned it up a bit.]
After a soundness fix in SI-3873, instantiation of dependent
method type results behaved differently depending on whether the argument
from which we were propagating information had a stable type
or not. This is particular to substitution into singleton types
over the parameter in question.
If the argument was stable, it was substituted into singleton
types, such as the one below in the prefix in `a.type#B`
(which is the longhand version of `a.B`)
scala> class A { type B >: Null <: AnyRef }
defined class A
scala> object AA extends A { type B = String }
defined object AA
scala> def foo(a: A): a.B = null
foo: (a: A)a.B
scala> foo(AA)
res0: AA.B = null
But what if it isn't stable?
scala> foo({def a = AA; a: A { type B <: String}})
res1: a.B = null
This commit changes that to:
scala> foo({def a = AA; a: A { type B <: String}})
res1: A{type B <: String}#B = null
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-8177 co-evolve more than just RefinedTypes
|
| | | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We look for any prefix that has a refinement class for a type symbol.
This includes ThisTypes, which were not considered before.
pos/t8177g.scala, neg/t0764*scala now compile, as they should
Additional test cases contributed by Jason & Paul.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I noticed the change when adapting Slick to work with
Scala 2.11 in `AbstractSourceCodeGenerator.scala`.
The behaviour changed in a70c8219.
This commit locks down the new, correct behaviour with a test.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7475 Private members aren't inheritable, findMember overhaul
|
