| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Only one seems to indicate something new:
((x: Int) => 0): NonClassType
I believe that we shouldn't pursue SAM translation for that case,
and fallthrough to Function1. That would allow for an implicit view
to finish the job.
|
|\
| |
| | |
[master] assorted fixes for vampire macros
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
[resubmit] Experimental Single Abstract Method support (sammy meets world)
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Inspired by test/files/run/t7398.scala and sammy_poly.
Added some notes to original tests.
Elaborating on that note: we don't yet desugar `f(a)` to `f.sam(a)`,
like we do for regular functions: `f(a)` becomes `f.apply(a)`.
It seems pleasingly symmetrical and is easy to implement,
but not sure it's a good idea...
|
| | | |
| | | |
| | | |
| | | | |
Addressing review feedback.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before this change:
scala> trait T { def apply(a: Int): Int }
defined trait T
scala> ((x: Int, y: Int) => 0): T
<console>:9: error: object creation impossible, since method apply in trait T of type (a: Int)Int is not defined
((x: Int, y: Int) => 0): T
^
After the change, these cases report the same errors as they do
*without* -Xexperimental.
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Under `-Xexperimental`, `typedFunction` invokes `synthesizeSAMFunction`
when the expected type for the function literal (`pt`) is not the built-in
`FunctionN` type of the expected arity, but `pt` does have a SAM
with the expected number of arguments.
PS: We'll require `import language.sam` instead of `-Xexperimental`,
as soon as the SIP is ready and there are more tests.
|
|\ \ \
| |_|/
|/| | |
SI-7899 Allow by-name inference under -Yinfer-by-name
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As usual, the hole has been exploited in the wild. While you
can't abstract over by-name-ness without running into the
ClassCastException or an un-applied Function0, there are cases
like the enclosed test where you can tiptoe around those
cases.
I've proposed a small change to Scalaz to avoid tripping over
this problem:
https://github.com/scalaz/scalaz/pull/562/files
But this commit I've also added a transitional flag, -Yinfer-by-name,
that they could use to back-publish older versions without code
changes. It is also an insurance policy for other projects that
might be exploiting the same hole.
|
|\ \ \
| | | |
| | | | |
SI-7239 A bonus test case from [scala-user]
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Thanks to Ilya Denisov for another sample [1] that progressed
with the fix for SI-7239, 174334b.
[1] https://groups.google.com/forum/#!topic/scala-user/8rZeCeiTYDo
|
|\ \ \ \
| | | | |
| | | | | |
SI-7895 Error reporting: avoid cascading, truncation
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`missing1.foo(missing2)` now reports `missing1` and `missing2` as
not found. Previously, only the first was reported.
The arguments are typed with an expected type ErrorType. We propagate
this through as the inferred type of anonymous function parameters
to avoid issuing cascading "missing parameter type" errors in code
like:
scala> Nil.mapp(x => abracadabra)
<console>:8: error: value mapp is not a member of object Nil
Nil.mapp(x => abracadabra)
^
<console>:8: error: not found: value abracadabra
Nil.mapp(x => abracadabra)
^
This was in response to unwanted changes in the output of existing
neg tests; no new test is added.
Similarly, we refine the errors in neg/t6436b.scala by to avoid
cascaded errors after:
type mismatch; found: StringContext, required: ?{def q: ?}
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Rather than just the first.
For example, `foo(wizzle, wuzzle, woggle)` should report all three
not-found symbols.
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | | |
If we can't type check the `Foo` in `case Foo(a, b) => (a, b)`,
we should enter error symbols for `a` and `b` to avoid further
errors being reported in the case body.
|
|\ \ \ \
| |_|_|/
|/| | | |
SI-7902 Fix spurious kind error due to an unitialized symbol
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Tracked down this error:
<none> is invariant, but type Y2 is declared covariant
<none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any
to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol
was not initialized.
This happends in the enclosed test for:
// checkKindBoundsHK()
hkArgs = List(type M3)
hkParams = List(type M2)
This commit forces the symbol of the higher-kinded type argument
before checking kind conformance.
A little backstory:
The `List(NoSymbol)` arises from:
class PolyTypeCompleter... {
// @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`),
// otherwise, the non-skolemized (external) type parameter symbols
override val typeParams = tparams map (_.symbol)
The variation that triggers this problem gets into the kind
conformance checks quite early on, during naming of:
private[this] val x = ofType[InSeq]
The inferred type of which is forced during:
def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match {
case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) =>
// If we don't save the annotations, they seem to wander off.
val annotations = stat.symbol.initialize.annotations
|
|\ \ \
| |/ /
|/| | |
Generalize OverridingPairs to SymbolPairs.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Increases your chance of knowing what is going on in
OverridingPairs. Introduces some new abstractions which I
hope for your own sakes you will put to use in some way:
RelativeTo: operations relative to a prefix
SymbolPair: two symbols being compared for something, and
the enclosing class where the comparison is being performed
Fixed a minor bug with access by accident by way of more
principled pair analysis. See run/private-override.scala.
Upgraded the error message issued on certain conflicts
to give the line numbers of both conflicting methods, as
opposed to just one and you go hunting.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given:
def id[A](a: A): A = a
def foo(f: (=> Int) => Int) = ()
foo(id)
We eta-expanded `id` and inferred `A` to be `=> Int` to satisfy the
expected type set forth by the formal parameter `f`.
We really shouldn't go about inferring types that we can't *write*.
Our attempt to do so led promptly into a `ClassCastException` in the
enclosed test.
This commit:
- drops by-name-ness during `inferExprInstance`
- tests that this results in a type error for the reported bug
(neg/t7899)
- tests that a method with a by-name parameter can still be
eta expanded to match function with a corresponding by-name
parameter (run/t7899)
- discovers the same latent CCE in pos/t7584
- now that would be a type error
- so we compensate by using placeholder functions rather than
eta-expansion.
- and move that that test to `run` for good measure.
|
|\
| |
| | |
SI-7886 unsoundness in pattern matcher.
|
| |
| |
| |
| |
| |
| |
| | |
Introduces -Xstrict-inference to deal with the significant
gap between soundness and what presently compiles. I'm hopeful
that it's TOO strict, because it finds e.g. 75 errors compiling
immutable/IntMap.scala, but it might be that bad.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I tracked down what was behind the issue described here:
// TODO: fix the illegal type bound in pos/t602 -- type inference
// messes up before we get here:
/*override def equals(x$1: Any): Boolean = ...
// Span[Any] --> Any is not a legal type argument for Span!
val o5: Option[com.mosol.sl.Span[Any]] =
*/
...which led straight to the unsoundness seen in neg/t7886.
It is dangerous to have an expected type of "Any" because
the type system will blithely ignore kind errors, since "Any"
can absorb anything. The consequence in this instance was
that inferring the case constructor for a type like
Foo[T <: Bound]
if done with expected type Any, this would come up with Foo[Any].
I altered it to use expected type Foo[T], which lets the dummy
type parameter survive to carry the bound forward and restores
sense to the inference. The before/after output for -Xprint:patmat
on pos/t602.scala is:
15c15
< if (x1.isInstanceOf[com.mosol.sl.Span[Any]])
---
> if (x1.isInstanceOf[com.mosol.sl.Span[K]])
17c17
< <synthetic> val x2: com.mosol.sl.Span[Any] = \
(x1.asInstanceOf[com.mosol.sl.Span[Any]]: com.mosol.sl.Span[Any]);
---
> <synthetic> val x2: com.mosol.sl.Span[K] = \
(x1.asInstanceOf[com.mosol.sl.Span[K]]: com.mosol.sl.Span[K]);
19,20c19,20
< val low$0: Option[Any] = x2.low;
< val high$0: Option[Any] = x2.high;
---
> val low$0: Option[K] = x2.low;
> val high$0: Option[K] = x2.high;
A file in the library depended (needlessly) on the unsoundness.
It was easy to fix but reminds us this may affect existing code.
|
|\ \
| | |
| | | |
Rework cff8b569 to heal the windows build.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- change newTermName to fix negative length names
rather than reject them
- restore the old logic in unspecializedName for names that
result from AnyRef specialized type parameters.
Why does fix the windows build? I remain none the wiser.
|
|\ \ \
| | | |
| | | | |
SI-7859 Value classes may wrap a non-public member
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We allow value class constructors to be non-public, so to be regular,
we should also allow the same for the param accessor.
This commit uses the 'makeNotPrivate' machinery to ensure that
the backend can generate the requisite unboxing calls.
This commit:
- refactors the code that enforced the restrictions, improving
a few error messages and positions. The remaining restrictions
needed some rewording in light of this change.
- allows value classes to have non-public, val parameters.
private[this] / protected[this] are still disallowed as value
classes don't have a concept of `this`, and because trying to
accomdate then would complicate the implementation.
This means that `class C(x: Int) extends AnyVal` is not allowed,
the user still must write `private val x: Int` or `val x: Int`.
- Outlaw `class C()()(val x: Int) extends AnyVal` to curtail any
bugs that might lurk in such a formulation.
The tests:
- Show that the privacy is respected in the typer phase, under
joint and separate compilation. We don't want a repeat performance
of SI-6601.
- Show that code that needs compiler-generated unboxes works under
both compilation scenarios
- Checks that the remaining restrictions are enforced and well
communicated.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
One of the previous commits relaxed the top-level restriction for bundles,
turning it into a requirement of staticness (i.e. bundles nested in static
objects are also okay now).
This means that we can now define bundles in repl. Almost.
There's still a little problem remaining that arises from the fact that
when compiling a line of input, repl doesn't automatically import all
previously defined symbols, but rather uses an heuristic to scan the
input and guess what symbols need to be imported.
Unfortunately for bundles, this heuristic fails, because when scanning
a macro definition that looks like `def foo = macro Macros.foo`, it thinks
that it's only necessary to import a term symbol called Macros (a vanilla
way of defining macro impls), but not a type symbol called Macros (a new
way of writing macro impls in bundles).
This commit fixes the problem by making the repl look for both term and
type symbols corresponding to the identifiers used in macro definitions.
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously it was enough to just extend scala.reflect.macros.Macro, which
created some loopholes, but now scalac enforces that bundles:
1) Are static (not necessarily top-level, but just static)
2) Are traits (objects shouldn't be bundles anyway, and classes bring
complications with their ctors which require special treatment in
generated classes, so why support them if they don't bring anything
new to the table?)
3) Are monomorphic (again, this brings unnecessary complications wrt
auxiliary code generation, so I don't see merit in supporting
polymorphic bundles, whatever that a polymorphic bundle could mean)
4) Don't provide concrete implementation for Macro.c (if they do then
what is the point?)
|
| |/
|/|
| |
| |
| |
| |
| | |
Most of this was revealed via -Xlint with a flag which assumes
closed world. I can't see how to check the assumes-closed-world
code in without it being an ordeal. I'll leave it in a branch in
case anyone wants to finish the long slog to the merge.
|
|\ \
| | |
| | | |
transformers no longer ignore UnApply.fun
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Second time's the charm. I remember trying to do exactly the same somewhen
around 2.10.0-M4, but then some continuations tests were failing.
Luckily, today everything went smoothly.
Please note that this fix changes the way that SI-5465 manifests itself.
Previously it produced type errors, now it simply crashes the compiler.
Therefore I had to attach the try/catch FatalError clause to invocations
of toolbox methods, so that compiler crashes get caught and translated to
ToolBoxErrors.
Also fixes SI-7871, and that clears the way for implementing quasiquotes
with conventional macros rather than relying on a special case in typer.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I had covered a few more cases working on this recently.
The warnings in several more cases involving polymorphism,
currying, and selects vs. idents receive more refined
handling.
|
|\ \ \
| | | |
| | | | |
SI-7629 Deprecate view bounds
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
This introduces a warning(/error with -Xfuture) with a general
migration advice. The IDE can use the warning to offer a quick fix
with the specific refactoring necessary.
|
|\ \ \
| | | |
| | | | |
Only look for unapplies in term trees
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since Scala 2.10.2, the enclosed test case has crashed
in the backend. Before, we correctly rejected this pattern match.
My bisection landed at a merge commit f16f4ab157, although both
parents were good. So I don't quite trust that.
I do think the regression stems from the changes to allow:
case rx"AB(.+)" =>
Examples of this are in run/t7715.scala.
This commit limits the search for extractors to cases where the
function within the Apply is a term tree.
|
|\ \ \
| | | |
| | | | |
SI-7848 Xlint no warn on $sym with params
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This idea brought to you by retronym.
Also improve implicitNotFound detection at typer;
and avoid checking the standard interpolation
expression for cases like s"some $$x".
Some minor refactorings of implicitNotFound strings.
The intersobralator allows extra spaces, i.e., trims.
|
|\ \ \ \
| | | | |
| | | | | |
SI-3971 error message carat mispoints at curried methods.
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Point at the beginning of the first argument list when
reporting an error, as this is most easily associated with
the application taking place (which may involve multiple
applies in succession.)
Thanks to retronym for figuring out why issuing a better
error message broke the compiler on non-erroneous compile runs.
The changes to "treesInResult" are the consequence.
|
|\ \ \ \
| | | | |
| | | | | |
SI-6120 multiple warnings at same position.
|
| |/ / /
| | | |
| | | |
| | | |
| | | | |
An error suppresses all further warnings at the same position,
but multiple warnings can be heard.
|
|\ \ \ \
| | | | |
| | | | | |
SI-6762 rename emptyValDef to emptySelfType.
|
| |/ / /
| | | |
| | | |
| | | |
| | | | |
Looks like emptyValDef.isEmpty was already changed to return
false, so now all that's left is a name which means something.
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
build.xml
src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
src/library/scala/concurrent/Future.scala
src/reflect/scala/reflect/internal/Types.scala
|
| |\ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Callbacks internal to the implementation of Futures should be
executed with the `InternalCallbackExecutor`, rather than the
user supplied `Executor`.
In a refactoring da54f34a6, `recoverWith` and `flatMap` no longer
played by these rules. This was noticed by a persnickety test in
Play.
Before this patch, the enclosed test outputs:
% scala-hash v2.10.3-RC2 test/files/run/future-flatmap-exec-count.scala
mapping
execute()
flatmapping
execute()
execute()
recovering
execute()
execute()
|