| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Backend does not need them after all, can just use nulls there.
So the functionality is only used for printing, and it makes
sense to move everything there.
|
|
|
|
| |
Prefer to access directly via symbol.
|
|
|
|
|
| |
Add comment what it is supposed to achieve and change the implementation
to follow the comment.
|
|
|
|
|
| |
1. There may be calls to super on non-this.
2. there may be calls to in-dirrect super-traits.
|
|\
| |
| | |
Add arrays to collection strawman
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's a funny interaction between:
elim-by-name(and erasure specifically);
lift-static;
supercalls.
object E extends F2(new B {})
Here we have an anonymous class new B {} that looks like it is created
by erasure.
For some reason this class forgets the link to original anonymous class:
SymDenot(E$annon1).initial.phase == erasure. I guess this is a bug.
Additionally, the owner of E$annon1 is an anonymous method inside E,
that is inSuperCall and thus we have an anonymous nested class that
has enclosingClass be package. This class looks like a top-level
anonymous class breaking a lot of assumptions in shared backend
and taking multiple branches in unexpected ways.
I'm not sure that this is a proper fix. I assume there's a bigger bug
around, but I don't quite understand it right now and I need to work on
other stuff.
Making a quick fix to unblock @odersky.
|
|/ |
|
| |
|
|
|
|
|
| |
This method is only used to find static initialisers.
Previously, it was always wrong, but we didn't care as we never had them.
|
|
|
|
|
|
|
| |
As a funny side-effect this allows to execute arbitrary code in static
initialisers:
@static val a: Unit = {println("loaded")}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`) ?
|
|
|
|
|
|
|
| |
Name, Symbol, Denotation, Type.
This uncovered two nonsensical comparisons, one in CollectEntryPoints,
the other in DottyBackendInterface.
|
|
|
|
| |
That knows that there exists only single magical array method.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the method `Arrays.newRefArray` was one of the only 3
methods that are kept generic after erasure. This commit removes
this magic, by making it take an actual `j.l.Class[T]` as
parameter.
Moreover, the methods `newXArray` all receive an actual body,
implemented on top of Java reflection, which means that a back-end
does not *have to* special-case those methods for correctness.
It might still be required for performance, though, depending on
the back-end.
The JVM back-end is made non-optimal in this commit, precisely
because it does not specialize that method anymore. Doing so
requires modifying the fork of scalac that we use, which should
be done separately.
The JS back-end is adapted simply by doing nothing at all on any
of the newXArray methods. It will normally call the user-space
implementations which use reflection. The Scala.js optimizer will
inline and intrinsify the reflective calls, producing optimal
code, at the end of the day.
|
| |
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Implement most of the Scala.js IR code generator.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Notable things that are not yet implemented:
* JS exports
* Scala.js-defined JS classes.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Notable things that are missing at this point:
* Pattern matching
* Try
* Most of the JavaScript interop
|
|/
|
|
|
|
|
|
| |
This pull request implements most of machinery needed for
https://github.com/scala/scala.github.com/pull/491
Only 3-rd check is not implemented by this commit.
I propose to get this in faster to fix #1149
|
|
|
|
|
|
| |
This required the ability to instantiate a different `Platform`
depending on settings, which, in turn, required to defer the
initialization of `ContextBase.platform`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduce a new entry point for the compiler in
`dotty.tools.dotc.Driver`:
```
def process(args: Array[String], simple: interfaces.SimpleReporter,
callback: interfaces.CompilerCallback): interfaces.ReporterResult
```
Except for `args` which is just an array, the argument types and return
type of this method are Java interfaces defined in a new package called
`dotty-interfaces` which has a stable ABI. This means that you can
programmatically run a compiler with a custom reporter and callbacks
without having to recompile it against every version of dotty: you only
need to have `dotty-interfaces` present at compile-time and call the
`process` method using Java reflection.
See `test/test/InterfaceEntryPointTest.scala` for a concrete example.
This design is based on discussions with the IntelliJ IDEA Scala plugin
team. Thanks to Nikolay Tropin for the discussions and his PR
proposal (see #1011).
|
|
|
|
|
|
|
| |
The interpreter needs to install a virtual directory
as output directory. This is not supported with the -d
option in ScalaSettings. The solution is to make the
output directory overridable in the GenBCode phase.
|
| |
|
|
|
|
|
| |
This adds some simple callbacks to Dotty that should be enough to
get basic integration from IntelliJ.
|
|
|
|
|
|
|
|
|
| |
The fact that the annotation comes first is weird, because when I write
an annotated type it's <type> @<annotation>. Also, annotated types
are like RefinedTypes in that they derive from a parent type. And in
RefinedTypes the parent comes first.
So swapping the arguments improves consistency.
|
|
|
|
|
|
|
| |
Otherwise they would always return the symbol in the original context
where Definitions was first created.
Also, cache two more arrays of symbols per run.
|
|
|
|
|
|
| |
TypeRef becomes Type, thus removing duplicates. Where
...Type was used in an extraction (e.g. ArrayType(...),
FunctionType(...)), we now use ...Of.
|
|
|
|
|
|
| |
1) Have symbol sets cached per run
2) Use methods Denotation#isPrimitiveValueClass, Denotation#isNumericValueClass
instead of calling contains directly on symbol sets.
|
| |
|
|
|
|
|
| |
Remve versions in Symbols, always go through version in
Denotations. Avoids having two equivalent ways to do the same thing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symbols are not stable between runs, so if some symbol referred
to from Definitions gets recompiled, there are then two Symbols
that are both visible, one referenced from Definitions, the other
the one that got compiled.
Thos led to a crash when e.g. compiling scala.Short, because the
newly compiled symbol was not recognized as a primitive value
class.
The present commit tries to make systematic changes without regard
to simplicity or aesthetics. This will be polished in future commits.
// ### comments signal areas that need further attention.
|
|
|
|
| |
Used to pass wrong context.
|
| |
|
|
|
|
|
| |
They should not be emitted for non-static modules.
All modules look as if they were static by backend.
|
|\
| |
| | |
Ycheck that methods defined in ClassInfo exist in tree.
|
| |
| |
| |
| |
| |
| |
| | |
used a wrong member function inside,
led to errors similar to:
java.lang.ClassFormatError: Duplicate method name&signature in class file dotty/tools/dotc/core/Types$WildcardType
|
|\ \
| | |
| | | |
Implement emission of annotations in GenBCode.
|
| |/
| |
| |
| | |
Fixes #688
|
|/ |
|
|\
| |
| | |
Fixes to generic arrays in backend.
|
| |
| |
| |
| | |
More magic is needed, as enumerating array symbols does not work in backend.
|
|/
|
|
| |
And adjust for it in DottyBackendInterface
|
|
|
|
| |
Did not handle this case before.
|
|\
| |
| | |
Fix typos, scaladoc tags, and some minor code smells.
|
| |
| |
| |
| |
| | |
I scanned the main sources with IntellIJ's spell checker and
corrected what showed up.
|
|/
|
|
|
|
| |
- Merge flatName and fullNameSeparated
- Treat nested members of modules specially, to conform to scalac conventions
- Use `~` as separator for term members.
|