| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
An optimization in implicit search.
ImplicitInfo-s themselves are cached (per-run) in Contexts
(for in-scope implicits) and in Implicits (for companion object
implicits.)
|
| |
|
|
|
|
| |
These show up often due to the way that searches for
implicit views operate: firstly `A=>B` is sought, and
failing that `(=>A) => B`.
|
| |\
| |
| | |
SI-7634 resurrect the REPL's :sh command
|
| | |
| |
| |
| |
| |
| | |
ProcessResult had a companion object in 2.10 that somehow disappeared in
2.11. It only called "new ProcessResult(...)", so the REPL might just as
well do that.
|
| |\ \
| | |
| | | |
Delay delambdafication and put the lambda's body into the containing class
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The differences when running with method based delambdafication aren't
important enough yet to create specialized versions that use method
based delambdafication.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This commit includes several tests where there's a variation in
signatures between inline delambdafication and method based
delambdafication.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
During development of late delmabdafying there was a problem where
specialization would undo some of the work done in uncurry if the body
of the lambda had a constant type. That would result in a compiler crash
as when the delambdafy phase got a tree shape it didn't understand.
This commit has a fix and a test.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
During development of delayed delambdafy there was a problem where
GenASM would eliminate a loadmodule for all methods defined within that
module even if those methods were static. The result would be broken
byte code that failed verification. This commit fixes that and adds a
test.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit puts a real body on the Delambdafy phase.
From a lambda, Delambdafy will create
1) a static forwarder at the top level of the class that contained
the lambda
2) a new top level class that
a) has fields and a constructor taking the captured environment
(including possbily the "this" reference)
b) an apply method that calls the static forwarder
c) if needed a bridge method for the apply method
3) an instantiation of the newly created class which replaces the
lambda
Trees.scala is modified to add two more convenient factories
for templates and classdefs.
A few basic tests are included to verify that it works as expected.
Further commits will have additional tests.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit is purely a refactor. It pulls code needed to adapt a tree
of one type into a tree of another type (by casting, boxing, coercing,
etc) out of Erasure and into common locations that will be usable
from the Delambdafy phase.
|
| | | |
| | |
| | |
| | |
| | | |
the body of a lambda into a local def. Tests are included to show the
different tree shapes.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This commit adds a do-nothing phase called "Delambdafy" that will
eventually be responsible for doing the final translation of lambdas
into classes.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The future-spec tests were spawning threads in object constructors which
meant they were on the ragged edge of entering deadlock from the static
initialization lock acquired during the static initialization blocks we
use to construct object reference fields. My work on restructuring
lambdas pushed it over the edge. This commit refactors the tests to use
class constructors rather than object constructors.
|
| |\ \ \
| | | |
| | | | |
Update eclipse setup instructions
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
According to @gkossakowski this project doesn't need to be imported (and,
furtheremore, importing it in the current form results in errors in Eclipse),
hence I'm removing it.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The version of some of the dependencies used in partest and scaladoc projects
did not match the version defined in `version.properties`. This prevented the
above projects from compiling correctly because the old dependencies were not
available in the local maven repository.
|
| |\ \ \ \
| | | | |
| | | | | |
Don't use runtime reflection from the batch compiler.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Not only does this save a big chunk of time on startup by avoiding
classloading and symbol table population, but it also seems to
improve steady state performance of the compiler.
Theory: JIT can optimize more aggressively without the
SynchronizedXxx decorators and the like being in the classloader.
See "Class Heirarchy Analyis" in [1]
This commit does this by:
- Avoiding use of FromString in pattern matcher, instead
using an established mechanism to parse system properties.
- Changes FromString back to use OptManifest. AFAICT, this
is now only a dependency of scala.tools.cmd.gen.Codegen,
so this is just a defensive measure.
The REPL still uses runtime reflection, so will pay a little
performance tax.
Benchmark:
avg shortest 10 times 744ms # before
avg shortest 10 times 675ms # after
[1] https://wikis.oracle.com/display/HotSpotInternals/PerformanceTechniques
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
- parallel collections should use default ExecutionContext
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Parallel collections now use `scala.concurrent.ExecutionContext`
by default.
The `ExecutionContextTaskSupport` is optimized to use the
`ForkJoinPool` underlying the `ExecutionContext` if possible.
Otherwise, a fallback `TaskSupport` that creates a reduction tree and
execute an operation through `Future`s is used.
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | | |
Fix typo in ParIterableLike
|
| |/ / / / /
| | | | |
| | | | | |
from Issue #3098, some typos.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7944 FOUND: stray undetermined type params in vicinity of implicits
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Implicit search created a nested Context into which the results of
its typechecking, namely, errors and undetermined type parameters
(roughly: those inferred as Nothing) are stashed.
The code the drives the process was checking for errors, but
discarded those undetermined type parameters.
This commit copies them from the child context to the parent,
which lets `Typer#adapt` to get to:
else if (hasUndetsInMonoMode) { // (9)
assert(!context.inTypeConstructorAllowed, context) //@M
instantiatePossiblyExpectingUnit(tree, mode, pt)
}
Our lost TypeVar has found its way home! The reward for which
is being instantiated, based on another type inference session
adapting the expression's type to the expected type.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Cleanup tools/*
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The scripts to fire up a compiler or REPL from build products
have bitrotted just enough to get rid of them. They do not
include the correct JLine, nor the scala modules.
I've also removed showPickled and diffPickled which were
based on these, and were also based on some code in
ShowPickled that no longer exists since 48cc8b4.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
I suggest using the scala-checkin-manual Jenkins job instead.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It delivered us the terser 't1234' naming convention for test
cases. Its work is done.
This commit does the bidding of the script's author:
> Despite its shameful hackiness, checked in for posterity.
> It'll live on forever in the git history; then I can remove it.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We no longer maintain a fork.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Only used on the 2.9.x series:
/code/jenkins-config grep -R epfl-build .
./jobs/scala-nightly-checkinit-2.9.x/config.xml: <command>./tools/epfl-build 2.9.x -Xcheckinit</command>
./jobs/scala-nightly-main-2.9.x/config.xml:./tools/epfl-build 2.9.x && ./tools/epfl-publish 2.9.x
/code/jenkins-config grep -R epfl-publish .
./jobs/scala-nightly-main-2.9.x/config.xml:./tools/epfl-build 2.9.x && ./tools/epfl-publish 2.9.x
|
| | | |/ / /
| |/| | |
| | | | |
| | | | | |
This has lived in scala/make-release-notes for some time.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Collections: remove redundant calls to .seq
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Students of Scala's history might recall that at introduction of
parallel collections, GenIterable et al were *not* added; instead
the parallel collections inherited from the existing interfaces.
This of course was an invitation to widespread disaster as any
existing code that foreach-ed over a collection might now experience
unwanted concurrency.
The first attempt to fix this was to add the `.seq` method to
convert a parallel colleciton to a sequential one. This was added
in e579152f732, and call sites in the standard library with
side-effecting foreach calls were changed to use that.
But this was (rightly) deemed inadequate, as we could hardly expect
people to change existing code or remember to do this in new code.
So later, in 3de96153e5b, GenIterable was sprouted, and parallel
collections were re-parented.
This commit removes residual needless calls to .seq when the static
type of the receiver is already a plain Iterable, which are no-ops.
|
| |\ \ \ \
| |_|/ /
|/| | | |
Microoptimization in implicit search
|
| | |/ /
| | |
| | |
| | | |
Avoid creating a throwaway list of parameter types.
|
| |\ \ \
| | | |
| | | | |
SI-7605 Deprecate procedure syntax
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit covers three cases:
- constructor definitions (def this {...})
- concrete method definitions (def foo {...})
- abstract method declarations (def foo)
The deprecation is currently hidden behind -Xfuture pending IDE support
for migrating users from procedures to methods.
|
| |\ \ \ \
| | | | |
| | | | | |
SI-6385 Avoid bridges to identical signatures over value classes
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As Paul noted in the comments to SI-6260 (from which I mined some
test cases) "there is no possible basis for conflict here":
scala> class C[A](val a: Any) extends AnyVal
defined class C
scala> class B { def x[A](ca: C[A]) = () }
defined class B
scala> class D extends B { override def x[A](ca: C[A]) = () }
<console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D
which overrides method x: [A](ca: C[A])Unit in class B
clashes with definition of the member itself;
both have erased type (ca: Object)Unit
class D extends B { override def x[A](ca: C[A]) = () }
^
What was happening?
Bridge computation compares `B#x` and `D#x` exitingErasure, which
results in comparing:
ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)])
These types were considered distinct (on the grounds of the unique
type hash consing), even though they have the same erasure and
involve the same value class.
That triggered creation of an bridge. After post-erasure eliminates
the `ErasedValuedType`s, we find that this marvel of enginineering is
bridges `(Object)Unit` right back onto itself. The previous
resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed
that we detected the zero-length bridge and reported it nicely, which
happened after related work in SI-6260. But we can simply avoid
creating in it in the first place.
That's what this commit does. It does so by reducing the amount
of information carried in `ErasedValueType` to the bare minimum needed
during the erasure -> posterasure transition.
We need to know:
1. which value class wraps the value, so we can box and unbox
as needed
2. the erasure of the underlying value, which will replace this
type in post-erasure.
This construction means that the bridge above computation now
compares:
ErasedValueType(C, Any) =:= ErasedValueType(C, Any])
I have included a test to show that:
- we don't incur any linkage or other runtime errors in the
reported case (run/t6385.scala)
- a similar case compiles when the signatures align
(pos/t6260a.scala), but does *not* compile when the just
erasures align (neg/t6260c.scala)
- polymorphic value classes continue to erase to the instantiated
type of the unbox: (run/t6260b.scala)
- other cases in SI-6260 remains unsolved and indeed unsolvable
without an overhaul of value classes: (neg/t6260b.scala)
In my travels I spotted a bug in corner case of null, asInstanceOf
and value classes, which I have described in a pending test.
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | | |
Rework build to allow publishing core to maven
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fix oversight in not skipping scalap's ad-hoc published docs on docs.skip.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`ant publish-core-signed-opt-nodocs` creates and publishes the smallest
possible set of jars (library/reflect/compiler) we can send to maven.
It uploads jars with class files and sources, but no docs
(so that we don't need to build scaladoc or any other modules).
`ant publish-core-signed-opt` is similar, but also publishes docs.
For local experimentation: `ant publish-core-local-nodocs`.
With a little bit more work, this can be used instead of `replacestarr`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use `unless` attribute in targets so that `docs.skip` influences dependency graph.
Create `scaladoc` task in `pack.core` so that we don't need `pack.done`
for publishing the core.
Move source bundle creation from `dist.src` to `osgi.core`/`osgi.done`.
Split dependencies of maven publishing into core/all variants:
`osgi.core` creates osgi bundles for just lib/reflect/comp.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Publish to maven with `ant publish.local`,
`ant publish`, or `ant publish.signed`.
For now, we must keep copying `src/build/maven/maven-deploy.xml`
to `dists/maven/latest.build.xml`, along with its dependencies,
as it's used by jenkins jobs and PR validation.
TODO: `inline src/build/maven/maven-deploy.xml` into `build.xml`.
|
| | | | | | |
|
