| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Faster and simpler Java 9 classpath implementation
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- 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.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Miscellania:
Miscellania is a small island off the northernmost part
of the Fremennik Isles - RunScape Wiki
Miscellanea:
A collection of miscellaneous objects or writings - Merriam-Webster
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The REPL has a long running instance of Global which outputs
classfiles by default to a VirtualDirectory. The inliner did not find
any of these class files when compiling calls to methods defined in
previous runs (ie, previous lines of input.)
This commit:
- Adds a hook to augment the classpath that the optimizer searches,
and uses this in the REPL to add the output directory
- Fixes the implementation of `findClassFile` in VirtualDirectory,
which doesn't seem to have been used in anger before. I've factored out
some common code into a new method on `AbstractFile`.
- Fixes a similar problem getSubDir reported by Li Haoyi
- Adds missing unit test coverage.
This also fixes a bug in REPL autocompletion for types defined
in packages >= 2 level deep (with the `:paste -raw` command).
I've added a test for this case.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Linux, the directory listing is not automatically sorted on Mac.
This leads to non-determistic ids of Symbols of the classes in a
directory, which in turn leads to instability of the ordering of
parents within inferred refinement types.
Notable, with this patch, we will stably infer:
```
scala> case class C(); case class D(); List(C(), D()).head
defined class C
defined class D
res0: Product with Serializable = C()
```
rather than sometimes getting `Serializable with Product` on
Linux. As such, I've removed the workarounds for this instability
in two test cases.
|
| |
|
|
| |
Make broken JAR files on compiler classpath cause a fatal error
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
:require was re-incarnated in https://github.com/scala/scala/pull/4051,
it seems to be used by the spark repl. This commit makes it work when
using the flat classpath representation.
|
| |
|
|
|
|
|
| |
Implements VirtualDirectoryFlatClassPath, which is required for the
presentation compiler created for the repl's tab-completion.
Various minor cleanups in the flat classpath implementation.
|
| |
|
|
|
|
|
|
|
|
| |
- 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".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit addresses code review comments.
The flat classpath is no longer the default classpath representation.
It was the default one just for the test purposes. For now it's not
desirable to make it permanently the default representation.
ZipAndJarFileLookupFactory is marked as sealed - it should help to
limit the ways of creating flat classpath instances for zips and jars.
|
| |
|
|
|
|
| |
There's added -YdisableFlatCpCaching option to ScalaSettings which
allows user to disable caching of flat representation of classpath
elements.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The part of the functionality of a ClassPathContext has been moved
to the base trait ClassPathFactory so it can be reused by the newly
created FlatClassPathFactory. This new implementation works in
similar manner as the ClassPathContext with this difference that it
just creates instances of flat classpath.
This change doesn't modify the behaviour of the compiler as the
interface and the way ClassPathContext works didn't change. Moreover
FlatClassPathFactory is currently unused.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's added the flat classpath type using ManifestResources,
closely related to the support for JSR-223 (Scripting for the Java
Platform). It uses classes listed in the manifest file placed in the
JAR. It's related to jar files so it's created using
ZipAndJarFlatClassPathFactory and is cached.
In general currently it's not possible to use it in Scala out of the
box (without using additional tools such as jarlister) as this
support is postponed. The old classpath has been properly prepared in
the PR created by @rjolly https://github.com/scala/scala/pull/2238
so the new one also got this feature.
ManifestResources is a ZipArchive without a real underlying file
placed on a disk and in addition implementing some methods declared
in AbstractFile as unsupported operations. Therefore the
implementation has to use the iterator. I wanted to have the similar
behaviour as in the case of directories and zip/jar files - be able
to get a directory entry for a package without iterating all entries.
This is achieved by iterating all entries only once and caching
packages.
This flat classpath type was the last needed one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds an implementation of flat classpath which can handle
both jar and vanilla zip files. In fact there are two versions - for
a class- and a sourcepath. Both extend ZipArchiveFileLookup which
provides common logic.
They use FileZipArchive. @gkossakowski made a comparison of different
ways of handling zips and jars (e.g. using javac's ZipFileIndex). He
stated that general efficiency of FileZipArchive, taking into account
various parameters, is the best.
FileZipArchive is slightly changed. From now it allows to find the
entry for directory in all directory entries without iterating all
entries regardless of a type. Thanks to that we can simply find
a directory for a package - like in the case of DirectoryFileLookup.
There's also added possibility to cache classpath representation of
classpath elements from jar and zip files across compiler instances.
The cache is just a map AbstractFile -> FlatClassPath. It should
reduce the number of created classpath and file instances e.g. in the
case of many ScalaPresentationCompilers in Scala IDE.
To prevent the possibility to avoid a cache, caches are created as
a part of factories responsible for the creation of these types of
the flat classpath.
|
| |
|
|
|
|
|
|
|
|
|
| |
There's added the flat classpath implementation for directories using
java.util.File directly. Since we work with a real directory - not
the AbstractFile - we don't need to iterate all entries of a file to
get inner entries of some package. We can just find an adequate
directory for a package.
There are added implementations for a class- and a sourcepath. Both
extend DirectoryFileLookup which provides common logic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's added AggregateFlatClassPath - an equivalent of
MergedClassPath from the old implementation. It is supposed to group
classpath instances handling different files being directories, zips
or jars.
Unlike in the case of the old (recursive) implementation, there won't
be a deep, nested hierarchy of classpath instances - just one root
(aggregate) and a flat structure of its children.
AggregateFlatClassPath ensures the distinction of classpath entries
and merges corresponding entries for class and source files into one
entry. This is required as SymbolLoaders class makes use of this kind
of ClassRepresentation.
There are also added unit tests which check whether
AggregateFlatClassPath obtains correct entries from classpath
instances specified in a constructor and whether it preserves the
ordering in the case of repeated entries. There's added a test type
of flat classpath using VirtualFiles so it's easy to check the real
behaviour.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces the base trait for flat classpath - an
alternative classpath representation. In accordance with the idea
and the experimental implementation of @gkossakowski, this
representation will try to make the best use of the specificity of
a given file type instead of using AbstractFile everywhere. It's
possible as .NET backend is no longer supported and we can focus on
Java-specific types of files.
FlatClassPath extends ClassFileLookup which provides the common
interface used also by existing ClassPath.
The new implementation is called flat because it's possible to query
the whole classpath using just single instance.
In the case of the old (recursive) representation there's the
structure of nested classpath objects, where each such an object can
return only entries from one level of hierarchy but it returns also
another classpath objects for nested levels included in it.
That's why there's added dedicated PackageLoaderUsingFlatClassPath in
SymbolLoaders - approaches are different so also the way of loading
packages has to be different. The new package loader is currently
unused.
There's added also PackageNameUtils which will provide common methods
used by classpath implementations for various file types.
|
|
|
The method asClasspathString is now deprecated. Moreover it's moved
to ClassFileLookup in the case someone was using it in some project
(an alternative classpath also will support it - just in the case).
All its usages existing in Scala sources are changed to
asClassPathString method. The only difference is the name.
Some operations on files or their names are moved from ClassPath to
the newly created FileUtils dedicated to classpath. It will be
possible to reuse them when implementing an alternative classpath
representation. Moreover such allocation-free extension methods like
the one added in this commit will improve the readability.
|
