Taking just the `jvmClasspathRoots` is not correct because it also
contains stuff needed for resolve to work correctly, such as JDK (full
or mock), stdlib (full or mock), reflect. JDK is obviously not needed in
the classpath, and stdlib/reflect are available via the parent class
loader, which is specifically reused across all tests to make them run
faster.
Also, don't try to create class loader for Java-only modules in
`JvmBoxRunner.processModule`. This happens, for example, for all tests
which were moved from `boxAgainstJava`.
Service ModuleStructureExtractor may break readabilty of test so it
should be used very carefully
Originally it is created for box inline test where we have different
runners on same testdata where one runner assumes that all files
in test in same module and other that they in different ones
This is needed for cases when test pipeline assumes that some part of
pipeline may be unavailable because of errors on previous stage.
For example, this may occur in some test which check something on IR
but contains backend facade for compiling binary dependencies. In
this case testdata with frontend errors is allowed if test has only
one module which should not be compiled
Rules of directives resolving:
- If no `MODULE` or `FILE` was declared in test then all directives
belongs to module
- If `FILE` is declared, then all directives after it will belong to
file until next `FILE` or `MODULE` directive will be declared
- All directives between `MODULE` and `FILE` directives belongs to module
- All directives before first `MODULE` are global and belongs to each
declared module
It contains different abstractions which represents parts of compiler
pipeline and artifacts produced by them, service structure, handlers
for analysis of artifacts
Alexander Udalov