| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
bincompat-forward.whitelist.conf
src/compiler/scala/tools/nsc/matching/Patterns.scala
src/compiler/scala/tools/nsc/transform/patmat/Logic.scala
src/compiler/scala/tools/nsc/typechecker/Infer.scala
src/scaladoc/scala/tools/nsc/doc/model/ModelFactory.scala
test/files/neg/t5663-badwarneq.check
|
| |\
| | |
| | | |
SI-7369 Avoid spurious unreachable warnings in patterns
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Unreachability analysis draws on the enumerated domain of types
(e.g sealed subclasses + null, or true/false), and also looks at all
stable identifier patterns tested for equality against the same 'slot'
in a pattern.
It was drawing the wrong conclusions about stable identifier patterns.
Unlike the domain constants, two such values may hold the same value,
so we can't assume that matching X precludes matching Y in the same
slot in a subsequent case.
For example:
val X: Boolean = true; val Y: Boolean = true
def m1(t1: Tuple1[Boolean]) = t1 match {
case Tuple1(true) =>
case Tuple1(false) =>
case Tuple1(false) => // correctly unreachable
}
def m2(t1: Tuple1[Boolean]) = t1 match {
case Tuple1(X) =>
case Tuple1(Y) => // spurious unreachable warning
}
//
// Before
//
reachability, vars:
V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
V1: (Boolean,) ::= null | ... // = x1
equality axioms:
V2=true#4 \/ V2=false#5 /\
-V2=false#5 \/ -V2=Y#3 /\
-V2=false#5 \/ -V2=X#2 /\
-V2=false#5 \/ -V2=true#4 /\
-V2=Y#3 \/ -V2=X#2 /\
-V2=Y#3 \/ -V2=true#4 /\
-V2=X#2 \/ -V2=true#4
//
// After
//
reachability, vars:
V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
V1: (Boolean,) ::= null | ... // = x1
equality axioms:
V2=true#4 \/ V2=false#5 /\
-V2=false#5 \/ -V2=true#4
|
| |\ \
| | |/
| |/| |
SI-6675 Avoid spurious warning about pattern bind arity.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In 692372ce, we added a warning (under -Xlint) when binding
a `TupleN` in to a single pattern binder, which wasn't allowed
before 2.10.0, and more often than not represents a bug.
However, that warning overstretched, and warned even when
using a Tuple Pattern to bind to the elements of such a value.
This commit checks for this case, and avoids the spurious warnings.
A new test case is added for this case to go with the existing
test for SI-6675:
$ ./tools/partest-ack 6675
% tests-with-matching-paths ... 3
% tests-with-matching-code ... 2
# 3 tests to run.
test/partest --show-diff --show-log \
test/files/neg/t6675-old-patmat.scala \
test/files/neg/t6675.scala \
test/files/pos/t6675.scala \
""
Testing individual files
testing: [...]/files/pos/t6675.scala [ OK ]
Testing individual files
testing: [...]/files/neg/t6675-old-patmat.scala [ OK ]
testing: [...]/files/neg/t6675.scala [ OK ]
All of 3 tests were successful (elapsed time: 00:00:03)
|
| |\ \
| | | |
| | | | |
Quiet down overloaded implicit warning.
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | | |
Apparently implicit classes product both a method symbol and
a module symbol, both of which are marked implicit, which left
this warning code believing there was an overloaded implicit
method.
|
| |\ \
| | | |
| | | | |
SI-7200 Test case for fixed type inference error.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Broken in 2.9.2 and 2.10.0, but working in 2.10.1
--- sandbox/2.10.0.log
+++ sandbox/2.10.1.log
def coflatMap[A >: Nothing <: Any, B >: Nothing <: Any](f: Test.Nel[A] => B): Test.Nel[A] => Test.Nel[B] = ((l: Test.Nel[A]) => Test.this.Nel.apply[B](f.apply(l), l.tail match {
case immutable.this.Nil => immutable.this.Nil
- case (hd: A, tl: List[A])scala.collection.immutable.::[A]((h @ _), (t @ _)) => {
- val r: Test.Nel[Nothing] = NelFoo.this.coflatMap[A, Nothing](f).apply(Test.this.Nel.apply[A](h, t));
+ case (hd: A, tl: List[A])scala.collection.immutable.::[?A1]((h @ _), (t @ _)) => {
+ val r: Test.Nel[B] = NelFoo.this.coflatMap[A, B](f).apply(Test.this.Nel.apply[A](h, t));
{
- <synthetic> val x$1: Nothing = r.head;
- r.tail.::[Nothing](x$1)
+ <synthetic> val x$1: B = r.head;
+ r.tail.::[B](x$1)
}
}
}))
b74c33eb86 represents the exact moment of progression. Comments
in pos/t7200b.scala, a minimal test that demonstrates the problem
without type constructors or code execution, pinpoint the line of
code responsible for the fix.
Incidentally, I'm currently on a train somewhere between Solothurn
and Biel, and am consequently without the power of scala-bisector.
Undeterred, and inspired by a line I saw in Skyfall last night
("sometimes the olds ways are better"), I just pulled off a two-hop
bisection. Take that, O(log N)!
The one remaining worry is the appearance of the type variable
?A1 in the output of -Xprint:typer for run/t7200.scala.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Under some order-dependent conditions (if source files arrive
in one order it happens, in the other order it does not) more
than one set of type parameters are created for a given class.
Previously this would lead to a crash in asSeenFrom when a type
parameter had to be matched up with a type application.
Now when that situation arises I compare them by name and log
a dev warning if it hits. This does not risk anything undesirable
happening because the wayward type parameter's owner is always
the right class; it's only the class type parameters which don't
include the wayward one. Since in a given type parameter list
names are unique, we have enough information to salvage the
search.
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
merge/v2.10.1-245-g5147bb2-to-master
Conflicts:
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
| |\ \ \
| | | | |
| | | | | |
SI-7377 Fix retypechecking of patterns on case companion alias
|
| | | |/
| | |/|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Some ancient code in Typers switches from PATTERNmode to
EXPRmode when encountering `stableF(...)`. It just
typechecks `stableF` and discards the arguments.
To the best of Martin's recollection, this has something
to do with the need to typecheck patterns rather late in
the compiler, after `a.b` had been translated to `a.b()`
in `Uncurry`. I'm not able to motivate this with tests
using `-Xoldpatmat`; was there ever an even older pattern
matcher that ran *after* uncurry?
What changed in 2.10.1 to expose this wrinkle? dfbaaa17
fixed `TypeTree.copyAttrs` to copy the original tree.
During the descent of `ResetAttrs`, sub-trees are duplicated
before begin further transformed. Duplicating the `Match`
in 2.10.0 would forget that the original tree of:
pat = (a: Int)Foo(_)
`----------`
`- TypeTree((a: Int)Foo), with original Select(..., "FooAlias")
The retypechecking would operate on the `MethodType`, rather
than the `Select`, which was not considered a stable
application.
For 2.10.x, I've just tightened up the condition to only
hit this if `args` is empty. I'm almost certain that the code
can be removed altogether, and I'll do that when this is merged
to master.
|
| |\ \ \
| | |/ /
| |/| | |
SI-7329 duplicate default getters for specialized parameters.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The default getter is generated with @specialized annotation if the
type parameter corresponding to the type of the parameter is
specialized. Consequently specialize pass tries to generate overloads.
Rather than pruning overloads to exclude duplicates, let's notice
that default getter specialization is not needed at all:
- The dynamic scope of default getter doesn't include specialized
method or class constructor.
- generic default getter is called even when calling specialized
method:
object V {
@specialized def foo[@specialized B](b: B = (??? : B)) = {}
foo[Int]()
}
gives:
invokevirtual Method V$.foo$default$1:()Ljava/lang/Object;
invokestatic (unboxToInt)
invokevirtual Method V$.foo$mIc$sp:(I)V
|
|\ \ \ \
| | | | |
| | | | | |
SI-7312 @deprecatedInheritance now ignores same-file subclasses
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Don't warn about the specialized subclass.
Fixed in the previous commit for a similar issue SI-7312.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This allows us to deprecate external inheritances as a prelude
to sealing a class, without enduring the warnings ourselved in
interlude.
|
|\ \ \ \ \
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
merge/v2.10.1-235-g4525e92-to-master
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/reflect/scala/reflect/internal/Types.scala
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Specialize assigns SpecialOverride info to a specialized method
even when there is a further specialization that should be forwarded
to.
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Tree reification fails for ExistentialTypeTree. The reason is that the
tree passed for reification (see reifyTree at GetTrees.scala) must have
not null tpe (see reifyBoundType at GenTrees.scala), which is not true
in the case of ExistentialTypeTree.
Why is it so? The tree passed to reifyTree was obtained in the reshape
phase of reificationusing using original TypeTrees that reporesent pre-
typer representation of a type. The problem is that original's tpe for
ExistentialTypeTree is not set.
So the solution to the issue is to create ExistentialTypeTree's original
in a such way that is has actual tpe set.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A highly satisfying rewrite of isSameType. It's faster, clearer,
shorter, better commented, and closer to correct. I am especially
pleased that t5580b stopped compiling, given that nobody seemed to
have much idea why it compiled in the first place.
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
topic/merge-2.10.x-to-v2.11.0-M2-74-g00e6c8b
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
build.xml
src/compiler/scala/reflect/reify/utils/Extractors.scala
src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
src/compiler/scala/tools/nsc/symtab/classfile/ICodeReader.scala
src/compiler/scala/tools/nsc/transform/patmat/MatchOptimization.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/partest/scala/tools/partest/nest/ReflectiveRunner.scala
src/reflect/scala/reflect/internal/Types.scala
src/reflect/scala/reflect/runtime/JavaUniverse.scala
test/files/run/inline-ex-handlers.check
test/files/run/t6223.check
test/files/run/t6223.scala
test/scaladoc/scalacheck/IndexTest.scala
|
| |\ \ \
| | | | |
| | | | | |
SI-7285 Fix match analysis with nested objects
|
| | | |/
| | |/|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The fix for SI-6146 introduced `nestedMemberType` to
enumerate sealed subtypes based on the (prefixed) type
of the scrutinee and the symbols of its sealed subclasses.
That method needed to widen `ThisType(modSym)`s to
`ModuleTypeRef(modSym)` before calling `asSeenFrom`.
However, this could lead to confused in the match analysis,
which sees `ModuleTypeRef` as distinct from singleton types
on the same modules (after all, they aren't =:=). Spurious
warnings ensued.
This commit makes two changes:
- conditionally re-narrow the result of `asSeenFrom` in `nestedMemberType`.
- present `a.b.SomeModule.type` as `SomeModule` in warnings emitted
by the pattern matcher.
|
| |/ /
| | |
| | |
| | | |
The fix arrived in SI-6022 / #1100 / 2.10.0-M7.
|
| |\ \
| | | |
| | | | |
SI-7259 Fix detection of Java defined Selects
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The fix for SI-3120, 3ff7743, introduced a fallback within
`typedSelect` that accounted for the ambiguity of a Java
selection syntax. Does `A.B` refer to a member of the type `A`
or of the companion object `A`? (The companion object here is a
fiction used by scalac to group the static members of a Java
class.)
The fallback in `typedSelect` was predicated on
`context.owner.enclosingTopLevelClass.isJavaDefined`.
However, this was incorrectly including Select-s in top-level
annotations in Scala files, which are owned by the enclosing
package class, which is considered to be Java defined. This
led to nonsensical error messages ("type scala not found.")
Instead, this commit checks the compilation unit of the context,
which is more direct and correct. (As I learned recently,
`currentUnit.isJavaDefined` would *not* be correct, as a lazy type
might complete a Java signature while compiling some other compilation
unit!)
A bonus post factum test case is included for SI-3120.
|
| |\ \ \
| | | | |
| | | | | |
SI-6921 SI-7239 Tread lightly during exploratory typing
|
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When deciding whether an Assign is a named argument or
and assignment expression, or when looking at arguments
that the current selection is applied to in order to
evaluate candidate implicit views, we risk polluting
the tree by setting error types. This happens even
if we are in 'silent' mode; that mode does silence the
error report, but not the side effect on the tree.
This commit adds strategic `duplicate` calls to
address the problem symptomatically.
Duplicating trees and retyping in general reach into
the domain of bugs umbrella-ed under SI-5464, but in
these places we should be safe because the tree is in
the argument position, not somewhere where, for example,
a case class-es synthetic companion object might be
twice entered into the same scope.
Longer term, we'd like to make type checking side effect
free, so we wouldn't need to play whack-a-mole like this.
That idea is tracked under SI-7176.
|
| |\ \ \
| | |/ /
| |/| | |
SI-7232 Fix Java import vs defn. binding precendence
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Java Spec:
> A single-type-import declaration d in a compilation unit c
> of package p that imports a type named n shadows, throughout
> c, the declarations of:
> - any top level type named n declared in another compilation
> unit of p
> - any type named n imported by a type-import-on-demand
> declaration in c
> - any type named n imported by a static-import-on-demand
> declaration in c
Scala Spec:
> Bindings of different kinds have a precedence defined on them:
> 1. Definitions and declarations that are local, inherited, or made
> available by a package clause in the same compilation unit where
> the definition occurs have highest precedence.
> 2. Explicit imports have next highest precedence.
|
|\ \ \ \
| | | | |
| | | | | |
[forward-port] SI-7232 Fix Java import vs defn. binding precendence
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Java Spec:
> A single-type-import declaration d in a compilation unit c
> of package p that imports a type named n shadows, throughout
> c, the declarations of:
> - any top level type named n declared in another compilation
> unit of p
> - any type named n imported by a type-import-on-demand
> declaration in c
> - any type named n imported by a static-import-on-demand
> declaration in c
Scala Spec:
> Bindings of different kinds have a precedence defined on them:
> 1. Definitions and declarations that are local, inherited, or made
> available by a package clause in the same compilation unit where
> the definition occurs have highest precedence.
> 2. Explicit imports have next highest precedence.
This is a forward port of 6e79370, which did not merge cleanly
and was omitted in the regular merge from 2.10.x to master.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
|\ \ \ \ \
| |_|_|_|/
|/| | | | |
[forward port] SI-7259 Fix detection of Java defined Selects
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The fix for SI-3120, 3ff7743, introduced a fallback within
`typedSelect` that accounted for the ambiguity of a Java
selection syntax. Does `A.B` refer to a member of the type `A`
or of the companion object `A`? (The companion object here is a
fiction used by scalac to group the static members of a Java
class.)
The fallback in `typedSelect` was predicated on
`context.owner.enclosingTopLevelClass.isJavaDefined`.
However, this was incorrectly including Select-s in top-level
annotations in Scala files, which are owned by the enclosing
package class, which is considered to be Java defined. This
led to nonsensical error messages ("type scala not found.")
Instead, this commit checks the compilation unit of the context,
which is more direct and correct. (As I learned recently,
`currentUnit.isJavaDefined` would *not* be correct, as a lazy type
might complete a Java signature while compiling some other compilation
unit!)
A bonus post factum test case is included for SI-3120.
Manual forward port of f046853 which was not merged as
part of the routine 2.10.x to master merge. The test case
uncovered a NullPointerExceptiion crasher in annotation
typechecking introduced in 5878099c; this has been prevented
with a null check.
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
|
|\ \ \ \
| | | | |
| | | | | |
SI-7296 Lifting the limit on case class arity
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When venturing above the pre-ordained limit of twenty
two, `Companion extends FunctionN` and `Companion.unapply`
are sacrificed. But oh-so-many other case class features
work perfectly: equality/hashing/stringification, the apply
method, and even pattern matching (which already bypasses
unapply.)
There was some understandable fear of the piecemeal when
I tabled this idea on scala-internals [1]. But I'd like
to persist as this limit is a needless source of pain for
anyone using case classes to bind to database, XML or JSON
schemata.
[1] https://groups.google.com/forum/#!topic/scala-internals/RRu5bppi16Y
|
|\ \ \ \ \
| |_|/ / /
|/| | / /
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* commit '395e90a786':
SI-7251, compiler crash with $.
SI-7240 fixes language feature lookup
SI-7233 Account for aliased imports in Erasure
SI-7233 Account for aliased imports in eta expansion.
SI-7132 - don't discard Unit type in interpreter
SI-6725 `f` interpolator now supports %n tokens
Conflicts:
src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala
src/compiler/scala/tools/nsc/typechecker/EtaExpansion.scala
src/repl/scala/tools/nsc/interpreter/ExprTyper.scala
|
| |\ \ \
| | | | |
| | | | | |
SI-7233 Account for aliased imports in EtaExpansion / Erasure
|
| | | | |
| | | | |
| | | | |
| | | | | |
When we discard the fiction of `scala.Any`.
|
| | | |/
| | |/|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Buggy:
treeCopy.Select(sel, sel.qual, sel.name) setSymbol null
Select(sel, sel.qual, sel.name)
Okay:
treeCopy.Select(sel, sel.qual, sel.name)
Select(sel, sel.qual, sel.symbol.name) // but doesn't copyAttrs!
It is an easy mistake to make, I've found one more occurance:
def foo(a: Any) = { import a.{toString => toS}; toS }
error: uncaught exception during compilation: scala.reflect.internal.FatalError
scala.reflect.internal.FatalError: class Object does not have a member toS
at scala.reflect.internal.Definitions$DefinitionsClass.scala$reflect$internal$Definitions$DefinitionsClass$$fatalMissingSymbol(Definitions.scala:1028)
A followup commit will address that problem.
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For the purposes of checkability warnings. This will
warn in case of:
scala> (1, 2) match { case Seq() => 0; case _ => 1 }
res9: Int = 1
Given how often Tuples are used as scrutinees, this is
a highly desirable place to warn.
I was orginally going to unlock this under -Xlint, and
could be easily convinced to go that way, given that
-Xfuture is a less popular option.
|
|\ \ \
| | | |
| | | | |
SI-6123: -explaintypes should not explain errors which won't be reported, new attempt
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Positive testcases compile reduced known offenders to verify that no output is
produced.
The negative testcase tests that -explaintypes actually produces output on code which fails
to compile. I have altered an existing testcase, `test/files/neg/abstract`,
adding -explaintypes to the flags.
This testcase is currently mostly ineffective, as partest currently ignores the
standard output (SI-7003). It will become more effective when SI-7003 is fixed.
But already now, testers would at least be able to notice extraneous output.
This argument is somewhat bogus, but this patch is no worse than the other ones
which are committed while SI-7003 is open.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Removed NotNull from tests and the parentage of AnyVal.
Removed the tests which were actually testing anything to
do with NotNull; massaged the others to forget NotNull and/or
not to name local things NotNull.
|
|\ \ \
| | | |
| | | | |
SI-7228, bug in subtyping.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Should speak for itself.
Whenever someone changed @switch from an error to a warning,
it broke all the tests which depended on the error. I added
-Xfatal-warnings to a couple which needed it. And one of those
tests was then failing, as it must now since we couldn't get away
with what was being attempted, so I moved it to pending.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Another in the category of bugs which involve narrowing,
widening, mediuming, dealiasing, weakening, normalizing,
denormalizing, supernormalizing, subnormalizing, and
double-bounded supersubnormalizing.
This is probably not the ideal fix, but it is an improvement.
|
|\ \ \ \
| |/ / /
|/| / /
| |/ /
| | |
| | | |
Conflicts:
src/compiler/scala/reflect/reify/Errors.scala
src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
|