| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wonder if the supply of copy-pasted code, and the bugs
which always accompany it, will ever run low. Here we have
a couple hundred lines of tree traversal which appears
roughly identical in structure to a different couple hundred
lines of tree traversal, except one calls methods called
putXXX and the other calls methods called writeXXX.
Except there was one call to writeXXX among all the putXXX
calls. Guess where it was crashing.
This entire file should be expunged.
|
|\
| |
| | |
SI-7367 scaladoc crash on constructing the model for annotations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Scaladoc only checks primary constructor when building annotation
model.
Here we instead find the constructor matching the annotation's symbol.
Also change TreeFactory.makeTree to return TreeEntity rather than
Option[TreeEntity] and force the caller check for EmptyTree.
|
|\ \
| | |
| | | |
Corrects link in README.rst
|
|/ / |
|
|\ \
| | |
| | | |
Update links to old website, in preparation for launch.
|
|/ /
| |
| |
| |
| | |
Removed the contact form, since it's redundant with mailing lists and
issue tracker.
|
|\ \
| | |
| | | |
SI-6943 warn on value class miscomparison.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a very dangerous situation running around when you
combine universal equality with value classes:
// All over your code
val x = "abc"
if (x == "abc") ...
// Hey let's make x a value class
val x = new ValueClass("abc")
// Uh-oh
There was until now no warning when comparing a value class
with something else. Now there is.
|
|\ \
| | |
| | | |
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)
|
|\ \ \
| | | |
| | | | |
SI-7355 Handle spaces in paths in Windows batch files.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Changed "%1%" and %2% to "%~1" and %~2 to allow spaces
in paths by surrounding quotes according to advice at:
http://stackoverflow.com/questions/473117/pass-path-with-spaces-as-parameter-to-bat-file
http://ss64.com/nt/syntax-args.html
|
|\ \ \
| | | |
| | | | |
Interactive scaladoc: demand new typer run when done.
|
| | |/
| |/|
| | |
| | |
| | | |
As of now, when backgroundCompile is in the same typer run as
scaladoc-fetching logic, typer is confused with stale symbols.
|
|\ \ \
| | | |
| | | | |
SI-7330 better error when pattern's not a value
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Somehow an applied type managed to sneak past the type checker in pattern mode.
Patterns must be values, though.
`case C[_] =>` was probably meant to be `case _: C[_] =>`
Advice is dispensed accordingly. (Generalizing the existing advice machinery.)
|
|\ \ \ \
| | | | |
| | | | | |
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.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Absolute path in error message.
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
As soon as you have a directory called "language" lying around,
you will appreciate why the advice given regarding SIP-18
should be "import scala.language..." not "import language..."
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-7388 Be more robust against cycles in error symbol creation.
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`Symbol#toString` was triggering `CyclicReferenceError` (specifically,
`accurateKindString` which calls `owner.primaryConstructor`.)
The `toString` output is used when creating an error symbol to
assign to the tree after an error (in this case, a non-existent
access qualifier.)
This commit catches the error, and falls back to just using the
symbol's name.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
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-7319 Avoid unflushed error/warning buffers in startContext
|
| | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Contexts share error/warning buffers with their
children, and this also applies ot the shared
`startContext`.
That context flushes the buffers in `startContext`
in `resetContexts`.
It also removes `typerReportAnyContextErrors`, which
appears to be an elaborate no-op. It is only ever passed
a context `c` which is a direct child of `this.context`.
So taking a buffered error out of `c` and reissuing it
into `this.context` merely re-inserts into into the same
error buffer. Consrast this with `silent`, which uses
a child context with a fresh error buffer.
SI-7319 Flush error buffer in typerReportAnyContextErrors.
After this change, we no longer rely on the backstop in resetContexts
introduced in the previous commit.
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
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-6286 IllegalArgumentException handling specialized method.
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
Specialize assigns SpecialOverride info to a specialized method
even when there is a further specialization that should be forwarded
to.
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
SI-7360 Don't let a follow-up TypeError obscure the original error.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When supplementing a fatal error message with context (current
compilation unit, tree, phase, etcetera), we must be cautious to
not to trigger another error which will obscure the original one.
Currently, `supplementErrorMessage` does its working a try catch
that only catches `Exception`. But this fails to catch
CyclicReferenceError (<: TypeError <: Throwable), as was seen
in a recent mailing list post by Greg Meredith.
This commit extends the catch clause.
|
|\ \ \ \
| | | | |
| | | | | |
Revert "SI-6387 Clones accessor before name expansion"
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 4e10b2c833fa846c68b81e94a08d867e7de656aa.
Add 6387 test to pending and 7341 to up-to-date.
|
|\ \ \ \
| | | | |
| | | | | |
SI-6386 typed existential type tree's original now have tpe set
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| | | | |
| | | | | |
SI-7289 Less strict type application for TypeVar.
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When a type constructor variable is applied to the wrong number of arguments,
return a new type variable whose instance is `ErrorType`.
Dissection of the reported test case by @retronym:
Define the first implicit:
scala> trait Schtroumpf[T]
defined trait Schtroumpf
scala> implicit def schtroumpf[T, U <: Coll[T], Coll[X] <: Traversable[X]]
| (implicit minorSchtroumpf: Schtroumpf[T]): Schtroumpf[U] = ???
schtroumpf: [T, U <: Coll[T], Coll[X] <: Traversable[X]](implicit minorSchtroumpf: Schtroumpf[T])Schtroumpf[U]
Call it explicitly => kind error during type inference reported.
scala> schtroumpf(null): Schtroumpf[Int]
<console>:10: error: inferred kinds of the type arguments (Nothing,Int,Int) do not conform to the expected kinds of the type parameters (type T,type U,type Coll).
Int's type parameters do not match type Coll's expected parameters:
class Int has no type parameters, but type Coll has one
schtroumpf(null): Schtroumpf[Int]
^
<console>:10: error: type mismatch;
found : Schtroumpf[U]
required: Schtroumpf[Int]
schtroumpf(null): Schtroumpf[Int]
^
Add another implicit, and let implicit search weigh them up.
scala> implicitly[Schtroumpf[Int]]
<console>:10: error: diverging implicit expansion for type Schtroumpf[Int]
starting with method schtroumpf
implicitly[Schtroumpf[Int]]
^
scala> implicit val qoo = new Schtroumpf[Int]{}
qoo: Schtroumpf[Int] = $anon$1@c1b9b03
scala> implicitly[Schtroumpf[Int]]
<crash>
Implicit search compares the two in-scope implicits in `isStrictlyMoreSpecific`,
which constructs an existential type:
type ET = Schtroumpf[U] forSome { type T; type U <: Coll[T]; type Coll[_] <: Traversable[_] }
A subsequent subtype check `ET <:< Schtroumpf[Int]` gets to `withTypeVars`, which
replaces the quantified types with type variables, checks conformance of that
substitued underlying type against `Schtroumpf[Int]`, and then tries to solve
the collected type constraints. The type var trace looks like:
[ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?U ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?Coll ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ setInst] Nothing ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing )
[ setInst] scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=scala.collection.immutable.Nil.type )
[ setInst] =?scala.collection.immutable.Nil.type( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?scala.collection.immutable.Nil.type )
[ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ setInst] Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Int )
[ create] ?T ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?U ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ create] ?Coll ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]] )
[ setInst] Nothing ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], T=Nothing )
[ setInst] Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], U=Int )
[ setInst] =?Int ( In Test#schtroumpf[T,U <: Coll[T],Coll[_] <: Traversable[_]], Coll==?Int )
The problematic part is when `?Int` (the type var originated from `U`) is registered
as a lower bound for `Coll`. That happens in `solveOne`:
for (tparam2 <- tparams)
tparam2.info.bounds.hi.dealias match {
case TypeRef(_, `tparam`, _) =>
log(s"$tvar addLoBound $tparam2.tpeHK.instantiateTypeParams($tparams, $tvars)")
tvar addLoBound tparam2.tpeHK.instantiateTypeParams(tparams, tvars)
case _ =>
}
|
|\ \ \ \
| |/ / /
|/| | | |
SI-6937 core type tags are no longer referentially unique
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Type tag factory used to evaluate the provided type creator in the
context of the initial mirror in order to maintain referential equality
of instances of standard tags. Unfortunately this evaluation might fail
if the mirror provided doesn't contain the classes being referred to.
Therefore I think we should avoid evaluating type creators there.
Note that failure of evaluation doesn't mean that there's something
bad going on. When one creates a type tag, the correct mirror /
classloader to interpret that tag in might be unknown (like it happens
here). This is okay, and this is exactly what the 2.10.0-M4 refactoring
has addressed.
Something like `res2.typeTag[A].in(currentMirror)` should be okay.
|
|\ \ \ \
| |_|/ /
|/| | | |
some more build fixes
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I recommend creating a build.properties file as follows:
```
locker.skip=1
starr.use.released=1
```
This will download the Scala version specified in starr.number,
use it to build quick, skipping locker.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
SI-7321 Memory leak in specialize on multiple compiler runs.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Currently the map is declared LinkedHashMap, which doesn't align with
other caching maps that are cleared on every run. Linkedness is only
needed to ensure deterministic order on the generated specialized
classes. The same can be accomplished by sorting generated classes
a-posteriori.
|
|\ \ \ \
| |/ / /
|/| | | |
Make build even more regular
|