summaryrefslogtreecommitdiff
path: root/src/detach/library
Commit message (Collapse)AuthorAgeFilesLines
* Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013Heather Miller2012-11-0217-17/+17
|
* Eliminate breaking relative names in source.Paul Phillips2012-09-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These things are killing me. Constructions like package scala.foo.bar.baz import foo.Other DO NOT WORK in general. Such files are not really in the "scala" package, because it is not declared package scala package foo.bar.baz And there is a second problem: using a relative path name means compilation will fail in the presence of a directory of the same name, e.g. % mkdir reflect % scalac src/reflect/scala/reflect/internal/util/Position.scala src/reflect/scala/reflect/internal/util/Position.scala:9: error: object ClassTag is not a member of package reflect import reflect.ClassTag ^ src/reflect/scala/reflect/internal/util/Position.scala:10: error: object base is not a member of package reflect import reflect.base.Attachments ^ As a rule, do not use relative package paths unless you have explicitly imported the path to which you think you are relative. Better yet, don't use them at all. Unfortunately they mostly work because scala variously thinks everything scala.* is in the scala package and/or because you usually aren't bootstrapping and it falls through to an existing version of the class already on the classpath. Making the paths explicit is not a complete solution - in particular, we remain enormously vulnerable to any directory or package called "scala" which isn't ours - but it greatly limts the severity of the problem.
* migrates stdlib and compiler to tagsEugene Burmako2012-04-231-16/+16
| | | | | * all usages of ClassManifest and Manifest are replaced with tags * all manifest tests are replaced with tag tests
* Adding some Sets/Maps to perRunCaches, and elim...Paul Phillips2011-07-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Adding some Sets/Maps to perRunCaches, and eliminating ambiguously named imports. Did a tour of the compiler adding a few longer-lived mutable structures to the per-run cache clearing mechanism. Some of these were not a big threat, but there is (almost) literally no cost to tracking them and the fewer mutable structures which are created "lone wolf style" the easier it is to spot the one playing by his own rules. While I was at it I followed through on long held ambition to eliminate the importing of highly ambiguous names like "Map" and "HashSet" from the mutable and immutable packages. I didn't quite manage elimination but it's pretty close. Something potentially as pernicious which I didn't do much about is this import: import scala.collection._ Imagine coming across that one on lines 407 and 474 of a 1271 file. That's not cool. Some poor future programmer will be on line 1100 and use "Map[A, B]" in some function and only after the product has shipped will it be discovered that the signature is wrong and the rocket will now be crashing into the mountainside straightaway. No review.
* I wrote a warning when nullary methods return U...Paul Phillips2011-04-281-1/+1
| | | | | | | | | | | | | | | 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.
* Updated copyright notices to 2011Antonio Cunei2011-01-2012-12/+12
|
* Imported sbt.Process into trunk, in the guise o...Paul Phillips2011-01-122-7/+7
| | | | | | | | | | | | | | | | | | | 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.
* minor code updates (detach plugin)michelou2010-12-085-12/+12
|
* removed duplicated error message for bad compil...michelou2010-11-183-6/+4
| | | | | | removed duplicated error message for bad compiler options made some cleanups in detach plugin code
* updates Scala examples, added detach pluginmichelou2010-11-1717-0/+1318