| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| | |
Remove scoverage sbt plugin
|
| |
| |
| | |
It doesn't work.
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
We'll write a facade in Scala.js to handle the unparsed JS-object
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Partest used to run tests with Dotty, but stopped at some moment.
I guess this line may have been deleted at some merge conflict.
|
|
|
|
|
| |
Dotty uses ammonite.terminal since April (53bd25f) which replaces JLine.
There is no reason to keep it anymore.
|
|
|
|
|
|
|
| |
* Do not reprint a tree that has not changed.
* Highlight changes with yellow and insertions in green.
* -Xprint-diff-del: Inserts the deleted parts of the tree in red
and the parts that where changed in magenta.
|
| |
|
|
|
|
| |
coursier
|
| |
|
|
|
|
|
|
| |
Since you still need to depend on multiple artifacts from within the
dotty project, a unified project is not feasible. A plugin would work
better of course.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Merge the sbt compiler bridge as a subproject of dotty
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Note that the dotty-bridge tests will not be run automatically by `test`
which is short for `dotty/test`, to run the dotty-bridge tests, do in sbt:
> dotty-bridge/test
> dotty-bridge/scripted
Original history: https://github.com/smarter/dotty-bridge/commits/master
|
|/ |
|
|
|
|
| |
Publishing artifacts under ch.epfl.lamp is easier.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The benchmark project generates a dubious exception when compiling
scala stdlib:
java.lang.ClassCastException: scala.tools.nsc.backend.jvm.BTypes$ClassBType
cannot be cast to scala.tools.nsc.backend.jvm.BTypes$ArrayBType
Upon investigation, this turns out to be a backend incompatibility
problem. The bench project runs with a previous version of scala-compiler.
Explicitly designating the scala-compiler version for bench fixes
the problem.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To test this with sbt, see
https://github.com/lampepfl/dotty/wiki/Using-Dotty-with-sbt
The following flags are added:
- -Yforce-sbt-phases: Run the phases used by sbt for incremental compilation
(ExtractDependencies and ExtractAPI) even if the compiler is ran outside of
sbt, for debugging.
- -Ydump-sbt-inc: For every compiled foo.scala, output the API
representation and dependencies used for sbt incremental compilation
in foo.inc, implies -Yforce-sbt-phases.
This commit introduces two new phases which do not transform trees:
- `ExtractDependencies` which extracts the dependency information of the current
compilation unit and sends it to sbt via callbacks
- `ExtractAPI` which creates a representation of the API of the current compilation
unit and sends it to sbt via callbacks
Briefly, when a file changes sbt will recompile it, if its API has
changed (determined by what `ExtractAPI` sent) then sbt will determine
which reverse-dependencies (determined by what `ExtractDependencies`
sent) of the API have to be recompiled depending on what changed.
See http://www.scala-sbt.org/0.13/docs/Understanding-Recompilation.html for
more information on how sbt incremental compilation works.
This phase was originally based on
https://github.com/adriaanm/scala/tree/sbt-api-consolidate/src/compiler/scala/tools/sbt
which attempts to integrate the sbt phases into scalac (and is itself based
on https://github.com/sbt/sbt/tree/0.13/compile/interface/src/main/scala/xsbt),
but it has been heavily refactored and adapted to Dotty. The main
functional differences are:
- ExtractDependencies runs right after Frontend (so that we don't lose
dependency informations because of the simplifications done by PostTyper),
but ExtractAPI runs right after PostTyper (so that SuperAccessors are
part of the API).
- `ExtractAPI` only extract types as they are defined and never "as seen
from" some some specific prefix, see its documentation for more details.
- `ExtractDependenciesTraverser` and `ExtractUsedNames` have been fused into
one tree traversal in `ExtractDependenciesCollector`.
TODO: Try to run these phases in parallel with the rest of the compiler
pipeline since they're independent (except for the sbt callbacks in `GenBCode`) ?
|
|
|
|
|
| |
Launching the repl with: `runMain dotty.tools.dotc.repl.Main` is now
working correctly
|
|
|
|
| |
That knows that there exists only single magical array method.
|
|
|
|
|
|
|
|
|
| |
The ScalaMeter issue is reported here:
https://github.com/scalameter/scalameter/pull/163/files
The issue exists both in v0.7 and v0.6. As dotty uses v0.6 now,
use this workaround until we upgrate to a new version of ScalaMeter.
|
|
|
|
|
|
| |
This allows to remove the ugly workaround for default methods.
There is also a slight adaptation for the new way to encode a
reference to the JS global scope in the IR.
|
| |
|
|
|
|
|
| |
This guarantees that we can bootstrap dotty without depending on
the binaries of scalajs-ir compiled by another Scala compiler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Scala.js back-end can be enabled with the `-scalajs`
command-line option. Currently, it adds one phase to the pipeline,
which emits .sjsir files from trees.
A sandbox project `sjsSandbox`, in `sandbox/scalajs/`, can be used
to easily test Scala.js compilation. One can run the `main()`
method of the `hello.world` object with
> sjsSandbox/run
The back-end only contains the bare mimimum to compile the hello
world application in the sandbox. Anything else will blow up
(for example, primitive method calls). It is a work-in-progress.
|
|
|
|
|
|
|
|
| |
This should be safe now that run tests do not take so much memory
anymore (cf #1033 and #1076).
It would be even better if we could figure out why we're using so much
memory, but that's less important than avoiding spurious test failures.
|
| |
|
|\
| |
| | |
Add a `dotty-interfaces` package
|