| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
When -feature has not been enabled, we were double counting
identical feature warnings that were emitted at the same position.
Normal error reporting only reports the first time a warning
appears at a position; feature warning counter incrementing
should behave the same way.
@hubertp: Fixed .check files that were broken in the original commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the refined build manager computes its change sets it mixes up
the types. It computes constructors of inner classes of the first
compilation that point to types of the second compilation. This
breaks a useful assertion in ExtensionMethods. The error you get for
t4245 is
java.lang.AssertionError: assertion failed: unexpected constructor
erasure A#6956.this.B#20211 for class B#6963
What goes on here is that the primary constructor of inner
class B#6963 points to the new version of that inner class
A#6956.this.B#20211. This happens during the computation of change
sets, not during normal compilation. Since it looks like the
computation of change sets is broken I have disabled the tests,
rather than disabling the assertion.
It seems that during residential compilation, the result type of a
constructor can be a different version of the enclosing class. I
could not reproduce this
|
| |
|
|
|
| |
I have seen this warning a bunch of times and it has not yet
been close to right.
|
| |
|
|
|
|
|
|
| |
Cleaned up and optimized code that maps between raw and pickled flags. Avoids mystery constants. Makes a whole bunch of new flags be pickled which were not pickled before (more precisely: Everything in InitialFlags with value greater than 1 << 31 which is not in FlagsNotPickled now gets pickled whereas before it wasn't. Among these: VARARGS, IMPLCLASS, SPECIALZED, DEFAULTINIT, SYNCHRONIZED. I am curious how many tickets will get fixed by this change.
The first one I noted is t5504, which previously enforced the buggy behavior through a neg check!
There are also some build manager check file changes that have to do with the fact that flags now print in a different order for performance reasons.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This was an interesting one. Basically an erroneous
import was creating an erroneous symbol for Array (similary
for other symbols that were 'found' in this import) which was
leading to all sorts of inconsistencies and spurious errors.
This wasn't a bug in ContextErrors but rather something that
existed for ages and was hidden from the general audience.
Review by @paulp.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes SI-963, since it was one of my random 30 it won the prize.
The trick after adding the stability check (which has been sitting
there commented out for 3+ years) was that implicit search depended
on the wrongness, because memberWildcardType would create scopes
with members of the form
?{ val name: tp }
And since a def shouldn't match that, fixing it broke everything
until I flipped it around: memberWildcardType should be seeking
?{ def name: tp }
It could also search for a mutable value: the relevant quality
is that it not be stable so it doesn't have a tighter type than
the members it hopes to match.
|
| |
|
|
|
|
|
| |
some tests (unreachability, exhaustivity, @switch annotation checking) are still run under -Xoldpatmat,
but that will change before we go into RC mode (then the test/ partest of this commit will be reverted)
removed irrelevant dependency on patmat
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
lib/scala-compiler.jar.desired.sha1
lib/scala-library-src.jar.desired.sha1
lib/scala-library.jar.desired.sha1
src/compiler/scala/reflect/internal/Definitions.scala
src/compiler/scala/reflect/internal/Importers.scala
src/compiler/scala/reflect/internal/Symbols.scala
src/compiler/scala/reflect/internal/Trees.scala
src/compiler/scala/reflect/internal/Types.scala
src/compiler/scala/tools/nsc/Global.scala
src/compiler/scala/tools/nsc/transform/Erasure.scala
src/compiler/scala/tools/nsc/transform/LiftCode.scala
src/compiler/scala/tools/nsc/transform/UnCurry.scala
src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
test/files/run/programmatic-main.check
test/files/speclib/instrumented.jar.desired.sha1
|
| | |
| |
| |
| |
| | |
One to go (which doesn't fail for me, which is interesting
because it's a VerifyError.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
At least for the value of fix which means "better than it was in
2.9." I accidentally spent a long while trying to fix something I didn't
realize I hadn't broken. But then I lucked into partially fixing it, so
that's good news.
See run/t5488-fn.scala if you want to see what still doesn't work.
(It's covered at SI-4770, which is now reopened.) Closes SI-5488.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The crickets at http://www.scala-lang.org/node/11901 were in
unanimous agreement that I should proceed as suggested.
- No arguments to @specialize gets you 10/10, not 9/10
- Fixed bugs in AnyRef specialization revealed by trying to use it
- Specialized Function1 on AnyRef.
- Changed AnyRef specialization to use OBJECT_TAG, not TVAR_TAG.
- Deprecated SpecializableCompanion in favor of Specializable,
which has the virtue of being public so it can be referenced
from outside the library.
- Cooked up mechanism to group specializable types so we don't
have to repeat ourselves quite so much, and create a few groups
for illustrative purposes. I'm not too serious about those names
but I used up all my name-thinking-up brain for the day.
- Updated genprod and friends since I had to regenerate Function1.
- Put tests for a bunch of remaining specialization bugs in pending.
Closes SI-4740, SI-4770, SI-5267.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In a stunningly unusual demonstration of farsightedness,
I was able to generate these changes only by running:
scala scala.tools.nsc.util.FlagsUtilCompiler
With this much time in between runs:
-// Generated by mkFlagsTable() at Mon Oct 11 10:01:09 PDT 2010
+// Generated by mkFlagsTable() at Thu Feb 02 20:31:52 PST 2012
|
| |
|
|
|
|
|
|
| |
given moment (instead of throwing type errors). This avoids previous problems where we were creating fake error trees in some incorrect places like in type completers in Namers etc. Implicits relied heavily on type errors being thrown but performance should stay the same due to some explicit checks/returns.
Some of the problems involved how ambiguous error messages were collected/reported because it was very random (similarly for divergent implicits). This should be more explicit now. Reduced the number of unnecessary cyclic references being thrown (apart from those in Symbols/Types which don't have a context and need to stay for now as is).
Review by @paulp, @odersky.
|
| |
|
|
|
| |
Wow, ten tests, that's unexpected. No review.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
for now, left the old if(settings.YdepMethTpes.value) guards in comments
removed *.flags containing -Ydependent-method-types also updated one
check file with one fewer error
no review
|
| |
|
|
|
|
|
|
|
|
|
| |
however, it must be possible to inline Ensuring, ArrowAssoc methods
renamed the public val x to something a little less intrusive
fixed check file to reflect better error message (see! it wasn't that uncommon for people to write `foo.x` -- NEWS AT ELEVEN)
no review
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Important note for busy commit log skimmers ***
Symbol method "fullName" has been trying to serve the dual role of "how
to print a symbol" and "how to find a class file." It cannot serve both
these roles simultaneously, primarily because of package objects but
other little things as well. Since in the majority of situations we want
the one which corresponds to the idealized scala world, not the grubby
bytecode, I went with that for fullName. When you require the path to a
class (e.g. you are calling Class.forName) you should use javaClassName.
package foo { package object bar { class Bippy } }
If sym is Bippy's symbol, then
sym.fullName == foo.bar.Bippy
sym.javaClassName == foo.bar.package.Bippy
*** End important note ***
There are many situations where we (until now) forewent revealing
everything we knew about a type mismatch. For instance, this isn't very
helpful of scalac (at least in those more common cases where you didn't
define type X on the previous repl line.)
scala> type X = Int
defined type alias X
scala> def f(x: X): Byte = x
<console>:8: error: type mismatch;
found : X
required: Byte
def f(x: X): Byte = x
^
Now it says:
found : X
(which expands to) Int
required: Byte
def f(x: X): Byte = x
^
In addition I rearchitected a number of methods involving:
- finding a symbol's owner
- calculating a symbol's name
- determining whether to print a prefix
No review.
|
| |
|
|
|
|
|
|
| |
Since I don't want to commit anything "interesting" until we ship 2.9, a
few uninteresting cleanups involving how types are printed, getting some
debugging code in shape to prepare for the long winter ahead, etc. No
review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wrote a warning when nullary methods return Unit. I wimped out of
including it in this patch because we had about 200 of them, and that's
what is fixed in this patch. I will add the warning to some kind of
"-Xlint" feature after 2.9.
This is motivated at least partly by the resolution of #4506, which
indicates the distinction between "def foo()" and "def foo" will
continue to jab its pointy stick into our eyes, so I believe we have a
minimal duty of at least following our own advice about what they mean
and not making a semirandom choice as to whether a method has parens or
not. Review by community.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix 'Symbol.companionModule' for the resident mode compiler. It was
confused by having modules being translated to lazy values. The
direct consequence was a crash in the build manager when looking at a
constructor using a default argument (compiled separately), but only on
the second run.
The resident compiler may run many times over, and symbols may be
reused. Therefore, a module symbol that has been translated to a lazy
val by refchecks is not guaranteed to have MODULE set on the next run
(even before refcheck). Flags are not part of symbol history. Instead we
rely on the fact that a synthetic lazy value must have been a module.
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
Closes #3059, #3895 (the only difference between this and r23232 is the
forced info transformation that ensures that nested objects are viewed
as lazy vals). sbt integration requires new starr for this commit to
work.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
As a brief diversion from real work, implemented Damerau–Levenshtein
and ran it on trunk to elicit obvious misspellings. Unfortunately
they're mostly in places like compiler comments which real people never
see, but I fixed them anyway. All those English Lit majors who peruse
our sources are sure to be pleased. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If I work on this patch any longer without checking in I will go
stark raving mad. It is broken up into a couple pieces. This one is
the changes to test/. It includes fixing a bunch of tests, removing
deprecated constructs, moving jars used by tests to the most specific
plausible location rather than having all jars on the classpath of all
tests, and some filesystem layout change (continuations get their whole
own srcpath.) This would be the world's most tedious review, so let's
say no review.
[Note: after this commit, I doubt things will build very smoothly until
the rest of the partest changes follow. Which should only be seconds,
but just in case.]
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Checking the symbols of parameters in overloaded methods didn't seem
to work in all cases. Apparently the enclosing class of the owner of
the parameter was changing during the compilations from trait to the
implementation class. This was causing annoying excessive compilation
for Types.scala.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fixes the problem mentioned in #2882, which seems to be the reason for #2280 - allow simple ananlysis on java sources. Review by dragos
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Exclude anonymous function classes from the definitions in dependency
analysis. This was causing spurious errors in for example Global.scala
and Interpreter.scala because of fresh names numbering. Also cleanup up
some code. No review.
|
| | |
|
| |
|
|
|
|
|
|
| |
Better test for checking existential types, where symbols not
necessarily have the same name. Added test for that. The problem
manifested itself in Globals.scala for variable classpath causing
execissive compilation without any reason. No review.
|
| | |
|
| | |
|
