| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Take advantage of the `/packages` index provided by the
jrt file system to avoid (expensive) Files.exist for
non-existent entries across the full list of modules.
- Extends ClassPath directly which leads to a simpler
implemnentation that using the base class.
- Add a unit test that shows we can read classes and packages
from the Java standard library.
Fixes scala/scala-dev#306
With this change bootstrap time under Java 9 was comparable to
Java 8. Before, it was about 40% slower.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://openjdk.java.net/jeps/220 changes the layout of the
JDK to encapsulate the provided libraries with the new module
system.
This commit modifies the compiler's classpath implementation
to scan the new location of these, the `jrt://` virtual filesystem.
This might need to be adjusted once we provide a means for
users to specify the subset of modules that they want to
depend on, but for now reclaims the ground we lost.
```
⚡ (java_use 9-ea; qscala)
Welcome to Scala 2.12.0-20160908-223617-7e4ebda (Java HotSpot(TM) 64-Bit Server VM, Java 9-ea).
Type in expressions for evaluation. Or try :help.
scala> import StackWalker._, java.util.stream._, scala.collection.JavaConverters._
import StackWalker._
import java.util.stream._
import scala.collection.JavaConverters._
scala> (() => StackWalker.getInstance(java.util.EnumSet.of(Option.RETAIN_CLASS_REFERENCE)).walk[Seq[String]]((s: java.util.stream.Stream[StackFrame]) => s.iterator.asScala.take(3).map(_.toString).toList)).apply().mkString("\n")
res0: String =
.$anonfun$res0$1(<console>:21)
.<init>(<console>:21)
.<clinit>(<console>)
scala>
```
I've marked the new class, `NioFile` as `private[scala]` to justify
the forward compatibility whitelist entry.
In principle we could use NioFile more widely rather than `PlainFile`
I tried this out in https://github.com/retronym/scala/commit/b2d0a17a
which passed CI. But to be conservative, I'm not submitting that change
at this point.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Added a deprecation warning for `-optimize`.
Later we'll also graduate `-Yopt` to `-opt`, probably for 2.12.0-M5.
|
|
|
|
|
|
|
|
|
|
| |
- Language imports are preceding other imports
- Deleted empty file: InlineErasure
- Removed some unused private[parallel] methods in
scala/collection/parallel/package.scala
This removes hundreds of warnings when compiling with
"-Xlint -Ywarn-dead-code -Ywarn-unused -Ywarn-unused-import".
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the classpath URL list in the runner settings to a lazy val.
Also clean up PathResolver's use of settings.classpath so
that the default is defined in one place, namely in settings,
where it can also be overridden.
The previous definition in both places was the same, namely,
`sys.env.getOrElse("CLASSPATH", ".")`, but the history of the
code path is fraught.
|
|
|
|
|
|
|
|
|
|
|
| |
The previous fix to deal with concurrent modification of system
properties doesn't handle null results introduced when a property
is removed.
This commit filters nulls for safety, and also adds a `names`
method to `sys.SystemProperties`.
The test is upgraded.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit contains some minor changes made by the way when
implementing flat classpath.
Sample JUnit test that shows that all pieces of JUnit infrastructure
work correctly now uses assert method form JUnit as it should do from
the beginning.
I removed commented out lines which were obvious to me. In the case
of less obvious commented out lines I added TODOs as someone should
look at such places some day and clean them up.
I removed also some unnecessary semicolons and unused imports.
Many string concatenations using + have been changed to string
interpolation.
There's removed unused, private walkIterator method from ZipArchive.
It seems that it was unused since this commit:
https://github.com/scala/scala/commit/9d4994b96c77d914687433586eb6d1f9e49c520f
However, I had to add an exception for the compatibility checker
because it was complaining about this change.
I made some trivial corrections/optimisations like use 'findClassFile'
method instead of 'findClass' in combination with 'binary' to find
the class file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit integrates with the compiler the whole flat classpath
representation build next to the recursive one as an alternative.
From now flat classpath really works and can be turned on. There's
added flag -YclasspathImpl with two options: recursive (the default
one) and flat.
It was needed to make the dynamic dispatch to the particular
classpath representation according to the chosen type of a classpath
representation.
There's added PathResolverFactory which is used instead of a concrete
implementation of a path resolver. It turned out that only a small
subset of path resolvers methods is used outside this class in Scala
sources. Therefore, PathResolverFactory returns an instance of a base
interface PathResolverResult providing only these used methods.
PathResolverFactory in combination with matches in some other places
ensures that in all places using classpath we create/get the proper
representation.
Also the classPath method in Global is modified to use the dynamic
dispatch. This is very important change as a return type changed to
the base ClassFileLookup providing subset of old ClassPath public
methods. It can be problematic if someone was using in his project
the explicit ClassPath type or public methods which are not provided
via ClassFileLookup. I tested flat classpath with sbt and Scala IDE
and there were no problems. Also was looking at sources of some other
projects like e.g. Scala plugin for IntelliJ and there shouldn't be
problems, I think, but it would be better to check these changes
using the community build.
Scalap's Main.scala is changed to be able to use both implementations
and also to use flags related to the classpath implementation.
The classpath invalidation is modified to work properly with the old
(recursive) classpath representation after changes made in a Global.
In the case of the attempt to use the invalidation for the flat cp it
just throws exception with a message that the flat one currently
doesn't support the invalidation. And also that's why the partest's
test for the invalidation has been changed to use (always) the old
implementation. There's added an adequate comment with TODO to this
file.
There's added partest test generating various dependencies
(directories, zips and jars with sources and class files) and testing
whether the compilation and further running an application works
correctly, when there are these various types of entries specified as
-classpath and -sourcepath. It should be a good approximation of real
use cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds dedicated FlatClassPathResolver loading classpath
entries as FlatClassPath.
Most of the common logic from PathResolver for the old classpath has
been moved to the base, separate class which isn't dependent on
a particular classpath representation. Thanks to that it was possible
to reuse it when creating an adequate path resolver for the flat
classpath representation.
This change doesn't modify the way the compiler works. It also
doesn't change nothing from the perspective of someone who already
uses PathResolver in some project or even extends it - at least as
long as he/she doesn't need to use flat classpath.
There are also added JUnit tests inter alia comparing entries created
using the old and the new classpath representations (whether the flat
one created using the new path resolver returns the same entries as
the recursive one).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parent commit, a3f71badf67bbaac1a4ba16f68211ea6e31aa473,
removed some logic preventing $class.class files to be
loaded. It did so only when the inliner was off.
Should this cause any issue, this option provides a means to
restore the old behavior by *never* loading $class.class files.
So, using -inline -Yno-load-impl-class will not load
$class.class files either (where previously -inline would
load them). The two old behaviors being available by *either*
using -inline *or* -Yno-load-impl-class (not both).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the inliner is on, it is necessary to load class
files containing the implementation of traits, i.e.,
those ending in $class.class. This is needed to be
able to inline these methods. However it is useless
if the inliner is disabled.
The previous logic avoided to put these files on the
classpath when the inliner was off. However, this
complicates things, and it makes the classpath
mechanism dependent on something totally unrelated.
On this basis, this commit removes that logic, and
instead trait impl .class files are always kept on
the classpath.
|
|
|
|
|
| |
in various places. This includes actors, compiler (mostly some new
macro parts) continuations, partest, scaladoc, scalap.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic in partest for snooping around for tools.jar
is moved to PathResolver, and ILoop uses it from there.
If JAVA_HOME is toolless, check out java.home.
The use case was that Ubuntu installs with `java` at
version 6 and `javac` at version 7; it's easy to wind
up with JAVA_HOME pointing at the version 6 JRE, as
I discovered. It's confusing when that happens.
In future, partest might run under 7 and fork tests
under 6, but those permutations are downstream.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
This commit shortens expressions of the form `if (settings.debug.value)` to
`if (settings.debug)` for various settings. Rarely, the setting is supplied
as a method argument. The conversion is not employed in simple definitions
where the Boolean type would have to be specified.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
What would you prefer?
adaptToMemberWithArgs(tree, qual, name, mode, false, false)
Or:
adaptToMemberWithArgs(tree, qual, name, mode, reportAmbiguous = false, saveErrors = false)
|
|
|
|
| |
With the exception of toString and the odd JavaBean getter.
|
|
|
|
|
|
| |
They are everywhere.
They defy categorization.
They are... M I S C
|
|
|
|
| |
This reverts commit 951fc3a486.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I want to get this commit into the history because
the tests pass here, which demonstrates that every commented
out method is not only unnecessary internally but has zero
test coverage. Since I know (based on the occasional source
code comment, or more often based on knowing something about
other source bases) that some of these can't be removed
without breaking other things, I want to at least record
a snapshot of the identities of all these unused and
untested methods.
This commit will be reverted; then there will be another
commit which removes the subset of these methods which I
believe to be removable. The remainder are in great need of
tests which exercise the interfaces upon which other
repositories depend.
|
|
|
|
|
|
|
|
|
| |
A dizzying number of unused imports, limited to files
in src/compiler. I especially like that the unused import
option (not quite ready for checkin itself) finds places
where feature implicits have been imported which are no
longer necessary, e.g. this commit includes half a dozen
removals of "import scala.language.implicitConversions".
|
| |
|
|
|
|
|
| |
And again, this is not a fatal error, so it should end with an Error,
and it should subclass not Throwable, but Exception.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are the regexp replacements performed:
Sxcala
-> Scala
Copyright (\d*) LAMP/EPFL
-> Copyright $1-2012 LAMP/EPFL
Copyright (\d*)-(\d*)(,?) LAMP/EPFL
-> Copyright $1-2012 LAMP/EPFL
Copyright (\d*)-(\d*) Scala Solutions and LAMP/EPFL
-> Copyright $1-2012 Scala Solutions and LAMP/EPFL
\(C\) (\d*)-(\d*) LAMP/EPFL
-> (C) $1-2012 LAMP/EPFL
Copyright \(c\) (\d*)-(\d*)(.*?)EPFL
-> Copyright (c) $1-2012$3EPFL
The last one was needed for two HTML-ified copyright notices.
Here's the summarized diff:
Created using
```
git diff -w | grep ^- | sort | uniq | mate
git diff -w | grep ^+ | sort | uniq | mate
```
```
- <div id="footer">Scala programming documentation. Copyright (c) 2003-2011 <a href="http://www.epfl.ch" target="_top">EPFL</a>, with contributions from <a href="http://typesafe.com" target="_top">Typesafe</a>.</div>
- copyright.string=Copyright 2002-2011, LAMP/EPFL
- <meta name="Copyright" content="(C) 2002-2011 LAMP/EPFL"/>
- * Copyright 2002-2011 LAMP/EPFL
- * Copyright 2004-2011 LAMP/EPFL
- * Copyright 2005 LAMP/EPFL
- * Copyright 2005-2011 LAMP/EPFL
- * Copyright 2006-2011 LAMP/EPFL
- * Copyright 2007 LAMP/EPFL
- * Copyright 2007-2011 LAMP/EPFL
- * Copyright 2009-2011 Scala Solutions and LAMP/EPFL
- * Copyright 2009-2011 Scxala Solutions and LAMP/EPFL
- * Copyright 2010-2011 LAMP/EPFL
- * Copyright 2012 LAMP/EPFL
-# Copyright 2002-2011, LAMP/EPFL
-* Copyright 2005-2011 LAMP/EPFL
-/* NSC -- new Scala compiler -- Copyright 2007-2011 LAMP/EPFL */
-rem # Copyright 2002-2011, LAMP/EPFL
```
```
+ <div id="footer">Scala programming documentation. Copyright (c) 2003-2012 <a href="http://www.epfl.ch" target="_top">EPFL</a>, with contributions from <a href="http://typesafe.com" target="_top">Typesafe</a>.</div>
+ copyright.string=Copyright 2002-2012 LAMP/EPFL
+ <meta name="Copyright" content="(C) 2002-2012 LAMP/EPFL"/>
+ * Copyright 2002-2012 LAMP/EPFL
+ * Copyright 2004-2012 LAMP/EPFL
+ * Copyright 2005-2012 LAMP/EPFL
+ * Copyright 2006-2012 LAMP/EPFL
+ * Copyright 2007-2012 LAMP/EPFL
+ * Copyright 2009-2012 Scala Solutions and LAMP/EPFL
+ * Copyright 2010-2012 LAMP/EPFL
+ * Copyright 2011-2012 LAMP/EPFL
+# Copyright 2002-2012 LAMP/EPFL
+* Copyright 2005-2012 LAMP/EPFL
+/* NSC -- new Scala compiler -- Copyright 2007-2012 LAMP/EPFL */
+rem # Copyright 2002-2012 LAMP/EPFL
```
|
|
|
|
|
|
|
|
|
| |
Builds a starr that uses stuff from scala.reflect.macros for macro activities.
Crucial makro thingies (such as makro.Context or makro.internal.macroImpl)
are temporarily left in place, because they are necessary for previous starr.
Macro tests will be fixed in a dedicated commit, so that they don't pollute
meaningful commits, making the life easy for reviewers and spelunkers.
|
|
|
|
|
| |
Review by @dragos, @jsuereth. Required bootstrapping because the starr was
ant tasks were invoking locker with -Ysourcepath instead of -sourcepath.
|
|
|
|
|
|
|
|
|
|
| |
Finally, -sourcepath is split into:
-Ysourcepath - for the library bootstrapping
-doc-source-path - for scaladoc links to source code
(squished the resident compiler test fix into this commit)
Review by @jsuereth.
|
| |
|
|
|
|
|
| |
Not sys.props("CLASSPATH"), sys.env("CLASSPATH"). No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some 11th hour modifications with the dual purpose of a smooth console
life for sbt and so the repl can be used on google app engine. Although
this patch may look largish to be entering at RC4, there isn't a lot
going on. It's trying to make these dangerous things:
- property and environment variable accesses
- thread creation
- signal handler installation
happpen in a sufficiently uniform way that people who don't want them
and places who don't allow them are not left with an unfixable situation
where things blow up inside private methods. Also, the (ahem) lower than
usual elegance levels are due to it being intended for 2.9.x as well.
Review by harrah.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attacked classpaths to get "." off of it when it's not actually
specified. The commit makes me nervous, but there's no invisible way to
fix something like this.
** Attention, this commit changes classpath handling **
We desperately need some way of testing that the classpath has certain
qualities and does not have others; partest is not that way. Closes
SI-4857, no review.
|
|
|
|
|
| |
We migrated the Scala wiki from Trac to Confluence. Review by rytz.
|
|
|
|
|
|
| |
results from the profiler, but it sure isn't slower and it shed 125
lines or so. No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Takes 30+% off the startup time for scala/scalac with a variety of
optimizations pinpointed by tracing method invocations. Frequent guest
stars in the parade of slowness were: using Lists and ListBuffers when
any amount of random access is needed, using Strings as if one shouldn't
have to supply 80 characters of .substring noise to drop a character
here and there, imagining that code can be reused in any way shape
or form without a savage slowness burn being unleashed upon you and
everything you have ever loved, String.format, methods which return
tuples, and any method written with appealing scala features which turns
out to be called a few orders of magnitude more often than the author
probably supposed.
This may be only the tip of the iceberg. 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.
|
|
|
|
|
|
|
|
| |
moved plugin folder back to 'misc/scala-devel/plugins'. moved bash
completion to scala-tool-support (see r21449). include continuations
in compiler sbaz package. replaced some tabs by spaces. review by
extempore.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
Altered classpath behavior when no default is given. Now in that case
the contents of environment variable CLASSPATH will be used as the
scala user classpath, and only if that is not present will "." be used.
Be advised that there are still various "hand assembled" sorts of
classpaths in trunk, and there's not yet any way to ensure they honor
this; things which use the normal Settings object should do the right
thing. No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Went ahead and implemented classpaths as described in email to
scala-internals on the theory that at this point I must know what I'm
doing.
** PUBLIC SERVICE ANNOUNCEMENT **
If your code of whatever kind stopped working with this commit (most
likely the error is something like "object scala not found") you can get
it working again with either of:
passing -usejavacp on the command line
set system property "scala.usejavacp" to "true"
Either of these will alert scala that you want the java application
classpath to be utilized by scala as well.
Review by community.
|
| |
|
|
|
|
|
| |
Review by community.
|
|
|
|
|
|
|
|
|
| |
Some much needed housecleaning regarding system properties. If you can
possibly resist the temptation, it'd be great if people could try to
go through the properties classes to get and set them, and also to set
property values somewhere fixed rather than using strings directly.
Review by community.
|