Add sourcepath to IDE setup #3949
Conversation
odersky
force-pushed
the
ide-sourcepath
branch
2 times, most recently
from
fc8c8df
to
d1db0dc
Compare
|
@allanrenucci Can you figure out what's wrong with test? |
|
@odersky The issue is when compiling with # Make sure output dir is empty
$ rm -rf out/*
$ sbt
> dotc -d out tests/run/hello.scala
> dotc -from-tasty -classpath out Test -Xprint:allThe second sbt command does not compile anything. This line returns |
|
FromTastyTests seems to be flakey (compilation order dependent?). I can't repeat test failures on the CI locally, and vice versa I get failures locally that are not an issue on the CI. @nicolasstucki can you look into this at some point? |
|
@allanrenucci I don't think the test failure is explained by the FromTasty tests. I mean your diagnosis was correct, but this did not cause a test failure. Even after the problem is fixed, we still fail in the same way. It's not in FromTasty. It seems towards the end of the run. Here is what we got: ./project/scripts/sbt ';dotc tests/pos/sbtDotrTest.scala -d out/scriptedtest1/; dotc -from-tasty -classpath out/scriptedtest1/ -d out/scriptedtest2/ dotrtest.Test; dotr -classpath out/scriptedtest2/ dotrtest.Test'
|
|
I see, it was a from tasty test after all. But I am at the end of my patience with them now. Somebody else will have to take this over and re-instantiate the failing tests. I never wanted to get involved with them in the first place, but they were so entangled with source trees that I had no choice. |
odersky
force-pushed
the
ide-sourcepath
branch
from
a6bebf1
to
b31333c
Compare
|
Current status: We can now construct trees from source, it's no longer required that the project is built so that we can read the Tasty trees. Also, we have now a cool find-references, which works very fast even for large code bases. For example it finds all 3360 references to "Context" in the Dotty project in under 3 seconds. Smaller sets take much less than a second. |
|
Current status: We can now also navigate to overridden symbols. |
|
I will fix the from tasty tests later. We could have issues that come from compilation order. The error that @allanrenucci pointed out means that the class is not found or cannot be loaded from the classpath. |
This allows the compiler to succeed even if the project is not fully built. It also gives navigation capability into directly dependent files.
Strangely, it seems that at least for simple dependencies, the IDE already knows about classes even if class name != source file name. @smarter Do you have an idea why?
Use less state: just a single field that can be either a tree or a tree provider This should make it easy to integrate sourfe files in IDE. The refactoring required a major refactoring in ReadTastyTreesFromClasses, which was a mess before. Hopefully it's not right. There are still "spurious" warnings coming from classes loaded twice. These will require a refactoring of FromTastyTest to avoid. They do not happen if the FromTasty frontend is invoked stand-alone.
1. Since Symbol.tree no longer automatically reads positions (it should not, really, that's what we have contexts for!), ReadPositions has to be turned on in therelevant tests. 2. Disabled simpleClass which fails again because wrong class file ends up being decompiled.
... so that it can be shared with SourcefileLoader in the future.
Various tweaks necessary so that symbols can be loaded from source.
After having implemented the interface between IDE and SymbolLoaders it turns out lateUnits is not needed, and lateFiles is used only internally.
- Don't fail if a class file is not found - Consult name tables of Tasty info for a possible match before loading tree. - Do the same for rename
Found to be usused by invoking findReferences, yay!
Don't parse a new tree, since this generates a new set of symbols which are hard to correlate with the old ones.
The previous version matched too much, as it as not comparing signatures. We no longer need to relate late-loaded symbols that should be the same as existsing ones, so the method can be simplified.
Simple comparison is enough, since we no longer have to deal with late-loaded symbols.
Lazy annotations need not be forced when cleaning up since any future evaluation wil be in a future context, so they cannot contain dangling completers.
We got into problems when the symbols were entered in one run and the tree was demanded in a subsequent run. In that case we'd need to time-travel back which the framework does not really support. The new scheme makes sure the typechecking is done at the same run as when the symbols were entered. It either immediately typechecks them, or if called during a compile, waits until the end of the compile. The latter twist is done so that we do not cause new cycles.
For modules we sometimes get the module class instead of the module val as symbol. In that case we should not filter references by the module class name but by the module name.
Despite what the comment said they were not skipped but traversed in their entirety, which led to "interesting" find-references results. Now only the call is traversed.
The previous cast can fail if applyOverloaded is used outside a compilation run. This can happen in the IDE, when annotations are forced. Reconstructing applications from Scala2 pickles calls applyOverloaded.
These are now shown in "definitions" if the cursor position is on a definition.
Following "name all the things" mantra.
We need that to be able to establish precise contexts.
Collect them all in NamerContextOps. Previously some were also in Typer and in Context itself.
odersky
force-pushed
the
ide-sourcepath
branch
from
a9e750c
to
d93a8eb
Compare
This allows the compiler to succeed even if the project is not fully built.
It also gives navigation capability into directly dependent files.