| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:
package scala.collection.mutable
Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:
// a.scala
package scala.foo
class Bar { new util.Random }
% scalac ./a.scala
% mkdir util
% scalac ./a.scala
./a.scala:4: error: type Random is not a member of package util
new util.Random
^
one error found
There are two ways to play defense against this:
- don't use relative paths; okay sometimes, less so others
- don't "opt out" of the scala package
This commit mostly pursues the latter, with occasional doses
of the former.
I created a scratch directory containing these empty directories:
actors annotation ant api asm beans cmd collection compat
concurrent control convert docutil dtd duration event factory
forkjoin generic hashing immutable impl include internal io
logging macros man1 matching math meta model mutable nsc parallel
parsing partest persistent process pull ref reflect reify remote
runtime scalap scheduler script swing sys text threadpool tools
transform unchecked util xml
I stopped when I could compile the main src directories
even with all those empties on my classpath.
|
| |
|
|
|
|
| |
With the exception of toString and the odd JavaBean getter.
|
| |
|
|
|
|
|
| |
4th round of clean ups (see r25293, r25285, r25292)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mopping up after the deprecation of exit and error. It is decidedly
non-trivial (at least for the IDE-impaired) to be completely sure of
which error function was being called when there were about twenty with
the same signature in trunk and they are being variously inherited,
imported, shadowed, etc. So although I was careful, the possibility
exists that something is now calling a different "error" function than
before. Caveat programmer.
(And let's all make it our policy not to name anything "error" or "exit"
from here on out....) No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removes a bunch of private functions which are never called. While based
on the nature of "private" one can generally feel pretty good that such
a thing is safe, there is always a chance the author had some future use
in mind. On that note I draw your attention in particular to:
(martin) Typers#stabilizedType: it "sounds" important, but most of it
has been commented out since 2007 and the little stub part is a never
called private.
(iulian) SpecializeTypes#makeTypeArguments: similarly sounds like a
cornerstone of a transformation until one notices it isn't used.
Unused methods are "attractive nuisances" for anyone (like myself) who
has to figure out how the compiler works by studying the compiler, for
reasons which are no doubt obvious. No review except as noted.
|
|
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
1. Added new Ant tasks to build the compiler in a memory-efficient way.
2. Modified Partest to make it more extensible and added an Ant task
to run it. 3. Created a SuperSABBUS build file (beta) using these new
tasks.
|