| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Fix for parser regression allowing 0-case match blocks. Closes #4217, no
review.
|
| |
|
|
|
|
| |
A raw tree was making its way into an error message. Removed. Closes
#4196, no review.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
closes #2741, #4079: pickling now ensures that a local type param with
a non-local owner, which will thus get a localized owner, will only get
a class as its localized owner if its old owner was a class (otherwise,
NoSymbol) this ensures that asSeenFrom does not treat typerefs to this
symbol differently after pickling.
todo: should we pro-actively set the owner of these type params to
something else than the type alias that they originate from? see notes
in typeFunAnon
review by odersky
|
| |
|
|
|
|
| |
review by extempore
(because of recent sin against this holy principle)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AnyVal types become source files instead of polite compiler
fictions.
!! You'll need a serious "ant all.clean" now. !!
As of this commit the system is fully bootstrapped and the
synthetic code eliminated: only the source files remain. The
sort-of-AnyVal-companions in scala.runtime.* have all been eliminated
because the actual companions can do everything; deprecated vals in
the scala.runtime package object point to the companions. This left
AnyValCompanion as the only AnyVal related thing in the runtime package:
that made little sense, so I deprecated and moved it as well.
Starr is based on r24066 plus this commit. Closes #4121. Review by rytz,
odersky.
|
| |
|
|
|
|
| |
Defer a check from the typer to refcheck so the error message makes some
sense. Closes #4174, review by rytz.
|
| |
|
|
|
|
| |
Look even harder for attempts to sneak "this" into superconstructor
arguments, and improve positioning. Closes #4166, no review.
|
| | |
|
| |
|
|
|
|
|
| |
What is, I think, the only possible solution to bug #4158 given the
current ways of controlling implicits. Let's just be glad there's one
instead of zero. Closes #4158, review by moors.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This outlaws explicit isInstanceOf tests on value types, which are
nonsense in any case, as long threatened in ticket #1872. Closes #1872,
review by rytz.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imported sbt.Process into trunk, in the guise of package
scala.sys.process. It is largely indistinguishable from the version in
sbt, at least from the outside.
Also, I renamed package system to sys. I wanted to do that from the
beginning and the desire has only grown since then. Sometimes a short
identifier is just critical to usability: with a function like error("")
called from hundreds of places, the difference between system.error and
sys.error is too big. sys.error and sys.exit have good vibes (at least
as good as the vibes can be for functions which error and exit.)
Note: this is just the first cut. I need to check this in to finish
fixing partest. I will be going over it with a comb and writing
documentation which will leave you enchanted, as well as removing other
bits which are now redundant or inferior. No review.
|
| |
|
|
|
|
|
|
|
| |
I had closed #2441 as a duplicate of that, but unfortunately #4114 did
not bring #2441 along with it. Then I realized I'm a programmer, not a
helpless trac watcher. As is often the case with thes things, fixing
that revealed a bug in the library. Closes #2441 for real, review by
odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A pretty severe bug in the recognition of tail call elimination.
It turns out that Tailcalls will perform "partial elimination" in
situations such as:
@annotation.tailrec final def f(x: Int): Int = f(f(x))
The outer call to f1 becomes a jump, but the inner call remains as
it was. I implemented @tailrec under the impression that if the
optimization had taken place, it had gone all the way. So this is now
fixed with a direct examination of the rewritten tree.
While I was in there I threw in some improved error reporting: the error
positioning is now on the call which is not in tail position rather than
the method declaration.
Closes #4135, no review.
|
| |
|
|
|
|
|
|
|
|
|
| |
scala> implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
<console>:10: error: Cannot construct a collection of type
List[List[Int]] with elements of type Int based on a collection of type
List[List[Int]]. implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
^
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently my flailing attempts to make things faster earned me the
pity of Tiark, who sent this monster patch which he probably dashed
off before the appetizers had been cleared away. All the steak is his
but I threw in a little sizzle so I could feel like a part of things.
It knocks about a bazillion miniseconds off the time spent in implicit
search.
This is the same patch martin already endorsed, give or take several
hundred lines of diff, so I will say no review, even though I know it
will be hard to look away. I trimmed most of the "speculative code"
(that is, the commented out bits) because it's getting awfully busy
along those sidelines. I will preserve the ideas in some more structured
form.
|
| | |
|
| |
|
|
|
|
| |
since r19547, which was for #1836 but loosened the noose too much.
Closes #4128, review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
| |
Generalized a pile of duplicated type caching code, but it's still
largely undeployed because I haven't figured out how to make it as fast
as the copy-pasted version, which bugs me like you wouldn't believe.
Cannot deal with making "Sophie's Choice" between performance and lack
of duplication. I left one deployment in because it fixed a bug, or at
least so I see it: can't see why one would want the two absent error
messages in t2641.check. Review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explaining something for the (largeish N)th time finally awoke me to
the fact that software can explain things. I labored a long time over
this error message: I'm sure it can still use work (and/or it will drive
scalaz users off some kind of cliff) but the simple common case people
have so much trouble with is lit up like a christmas tree and for this I
will take some bullets.
build/pack/bin/scala -e 'class Foo[T] ; Set[Foo[AnyRef]]() + new
Foo[String]' :1: error: type mismatch; found : this.Foo[String]
required: this.Foo[java.lang.Object] Note: String <: java.lang.Object,
but class Foo is invariant in type T. You may wish to define T as +T
instead. (SLS 4.5) class Foo[T] ; Set[Foo[AnyRef]]() + new Foo[String]
^
Review by moors.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Stops barking up the wrong tree with -Ywarn-dead-code. The origin of its
issues was twofold:
1) synchronized acts by-name without being by-name (ticket #4086) 2)
warnings are swallowed if context.reportGeneralErrors is false
Those two plus a dash of bitrot. In any case it's at its all time
happiest now. It found all the dead code related fixes in this commit.
Way to go, -Ywarn-dead-code! Review by odersky.
|
| |
|
|
|
| |
enjoy fewer spurious warnings. Closes #1681, no review.
|
| |
|
|
|
|
|
|
|
|
| |
Told the boy trying to plug the dike holes that he can go home. Instead
of trying to catch unpositioned EmptyTrees from the XML parser, don't
generate them. It's the kind of commit you would tell your grandkids
about if your grandkids could sit still for five seconds: fixes bugs
by deleting code and eliminates extraneous error messages to boot (see
.check diffs.) No review.
|
| |
|
|
|
|
|
|
| |
Turned an assert/compiler crash into an error message. Admittedly the
error output is still terrible (the XML positioning looks like it came
from an RNG) but more helpful than the crash. Also misc advantage of a
handy new method. Closes #4069, no review.
|
| | |
|
| |
|
|
|
|
| |
again: relax access boundry check for overriding protected java members.
review by eugenevigdorchik.
|
| |
|
|
|
|
|
| |
Moved ClassfileAnnotation/StaticAnnotation/Annotation/TypeConstraint
into scala.annotation and enabled the deprecated type aliases in scala.*
to point there. Also enclosed is a new starr to bootstrap. No review.
|
| |
|
|
|
|
|
|
|
|
| |
Introducing scala.system, the product of a whirlwind couple of
hours. More useful stuff than you can shake three sticks at. See the
scala.system package object. It's even documented.
And since it has methods error and exit, proceeded to deprecate the ones
in Predef. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting the mopping up now that names have some more sense of their
place in the universe. Cleaned up some heavy multi-boolean logic. Added
more documentation on the relationships between entities in Symbols and
some other compiler things which often blur together.
Fun fact: the incorrect usage of nme.ScalaObject in Contexts which I
reported when first broaching the namespace subject became a compile
time error during the writing of this patch, because there is no longer
any such thing as nme.ScalaObject. It's a little bit like magic. No
review.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
warnings. Fixed some bugs revealed by said warnings, and made some minor
changes to avoid warnings. (Technically it's not a bug to have unrelated
classes compare as equal, but it so often is a bug that it behooves us
not to do it intentionally so the warnings stand out.) Disabled the most
useful warning for the moment since it'd be wrong with some frequency.
No review.
|
| |
|
|
|
|
|
| |
Parser relaxation so that one can name the type variables in a
constructor pattern match: this is a prerequisite to realizing the full
potential of gadts. (Nothing new works here however.) No review.
|
| |
|
|
|
|
|
| |
Found several minor thigns wrong with checkSensible, which tries to
issue warnings for comparisons which will always be true or false. No
review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"I invite everyone to change this rule, and observe what breaks!"
This much beloved comment from #1208 has been on my radar for two years.
The worm has turned. Closes #1208. The inferred type of an object is now
Foo.type instead of "object Foo". What once was this:
scala> val x: Map[Int, Singleton] = Map(1 -> None)
<console>:5: error: type mismatch;
found : (Int, object None)
required: (Int, Singleton)
Now exudes a pleasing aura of workingness:
scala> val x: Map[Int, Singleton] = Map(1 -> None)
x: Map[Int,Singleton] = Map(1 -> None)
No review.
|
| |
|
|
|
|
| |
Did some more polishing on the infamous partial function error message.
No review.
|
| |
|
|
|
|
| |
Some work on error messages, somewhat based on ideas in #3092. No
review.
|
| |
|
|
|
| |
Review by Rytz.
|
| |
|
|
|
|
|
| |
Added varargs annotation.
Review by Rytz.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some refinement of the error messages when the found and required types
have the same simple names. No longer must we watch people scratch their
heads at such messages as:
found : scala.collection.Set[String]
required: Set[String]
Now so clear you could enjoy a movie through it:
found : scala.collection.Set[String]
required: scala.collection.immutable.Set[String]
No review.
|
| |
|
|
|
|
|
|
|
| |
Half of an implementation of sealedness for java enums. Since it's only
half it's behind -Xexperimental, but it works like a charm for the half
where it works (that being compiling against bytecode.) Need input on
how to approach the source half. References ticket #2442. Review by
moors.
|
| |
|
|
|
|
| |
protected[this] members should be accessible to super.x calls. Closes
#464, review by odersky.
|
| |
|
|
|
|
|
|
|
| |
the same issues as JavaConversions with respect to overloading implicit
methods making them inaccessible to view bounds. Fixed JavaConverters.
Added a warning for when people overload parameterized implicits: in
almost all cases the name is irrelevant so there's little point in
unwittingly suffering degraded functionality. No review.
|
| |
|
|
|
|
|
| |
Don't crash the compiler for the 'companions in different files'
error. This turned out to be pretty bad for the presentation compiler.
References #1286. Review by extempore
|
