Analysing file file with diagnostics on each step of post-processings is rather expensive operation so the inspection-like post-processings which don't require diagnostic information was separated from ones that need it
Related to #KT-31848
annotationsViaActualTypeAliasFromBinary.kt is ignored because
ExpectActualRemover can't find actual for the expected constructor of
Anno now, because `ExpectedActualResolver.findActualForExpected`
incorrectly filters out actual declarations without any source file, and
Java classes loaded in the fast mode don't have any source files.
This will need to be fixed separately, probably by making
ExpectedActualResolver look for the actual class of an expected class
member first (with source file-based filtering), and then
unconditionally locating the corresponding member there
After b602c08773, this test started to put all .java files to the
dependencies when compiling .kt files, _in addition_ to the already
compiled class files from those Java sources. This is incorrect because
the test should actually check how Kotlin compiles _against_ Java
binaries. The other behavior (compiling against Java sources) is already
supported and used in normal box tests with .java sources.
However, we can't simply filter out all .java files before calling
`super.doMultiFileTest` because many of those contain directives
(WITH_RUNTIME, FULL_JDK, etc.) and we should load them in
`CodegenTestCase.compile`. As a workaround, remove '.java' file
extension to prevent their compilation but still be able to resolve
directives.
'getContributedDescriptors' isn't obliged to apply filters, inlcuding
kindFilter, and may return declarations of different kind, so we have to
call 'filterIsInstance' explicitly
Or --scan will fail (see KT-31891 for more details).
To do it in same thread we should parse output on output stream calls.
TCServiceMessageOutputStreamHandler will do that.
Also, all new lines now preserved, so TCServiceMessagesClient should
ignore new lines after messages. New ignoreLineEndingAfterMessage setting
will do that.
#KT-31891 Fixed
There was one monolith protobuf at irHeader.knd, it was
split up onto 4 parts due to performance issues:
- a small irHeader with some basic info about a module
- symbols table
- types table
- strings table
These 3 tables are then mmapped and accessed by index.
The initial assumption were that inside compiler and test framework all
line breaks are normalized, because we read text files only through IDEA
utils (which do normalization).
The mistake was that 'StringBuilder.appendln()' appends
'System.lineSeparator()' as well, so it's not enough to only check that
we don't load files from disk without normalizing whitespaces.
Note that using 'it.replace(System.lineSeparator(), ...)' would be
incorrect too, because actually we have strings with two kinds of line
breaks here (normalized and not normalized), so we're looking for both
via simple regex.
The main issue is that we have CombinedModuleInfo in old IDE Resolve,
which essentially merges platfor-modules together with its
dependsOn-parents. It conceals real module structure, which is fine for
practically all clients except for ExpectedActualDeclarationChecker.
In particular, it is nearly impossible to check expect/actual via
ModuleDescriptors, because you'll always get one and the same
'merged'-module descriptor.
So, this commit rewrites IdeaModuleStructureOracle in the following way:
- use ModuleInfos instead of ModuleDescriptor, as they allow more
fine-grained way to work with modules
- use 'unwrapModuleSourceInfo' in seemingly random places in order to
get real, non-merged moduleInfos
- carefully convert them back to ModuleDescriptors, because EADC work
with descriptors
This is still not an ideal solution. In particular, last step is flawed:
conversion back to ModuleDescriptors will always return merged
moduleDescriptor for platform-modules. There's no easy way to fix that
except for removing CombinedModuleInfo altogether, so we leave it as
known issue.
Also, there are some weird changes in testdata (again, because sometimes
we see several modules merged together), but they are mostly confusing
rather than plain incorrect.
matching
This commit makes several changes in testdata:
- compiler multiplatform tests now contain newly introduced diagnostics
about AMBIGIOUTS_ACTUALS
- MultiModuleHighlighitng tests now contain proper reports about
ACTUAL_MISSING:
- ACTUAL_MISSING should be indeed reported in them, because those
tests don't contain dependsOn edges, only usual intermodule
dependencies
- This error wasn't reported here because expect/actual diagnostics in
common module used to be reported by PlatformExpectedAnnotator, which
had a bit flawed logic for deremining common-modules: it checked for
presence of implementing modules. In those tests, common module has no
implementing modules, so Annotator was returning silently
Note that such configurations (common module without implementing
modules) are almost impossible in real-life projects
- After removal of PlatformExpectedAnnotator, we use
ExpectedActualDeclarationChecker in common modules, which launches all
checks properly
- some QuickFixMultuModuleTests now contain proper reports about
ACTUAL_MISSING. This change is also connected with
PlatformExpectedAnnotator, but now for different reason:
- QuickFixMultiModuleTest used to check for errors in file by running
'analyzeWithAllCompilerChecks' and inspecting returned BindingTrace.
For common modules, there were no diagnostics about expect/actuals in
that trace, because there were no ExpectedActualDeclarationChecker
(and PlatformExpectedAnnotator was reporting diagnostics in ad hoc
trace).
- Again, now we inject EADC in common modules properly, so we see
those errors in trace and report them in test
Inject it instead of calling constructor manually and passing instance
directly into the container. This allows to accept some components in
constructor of ExpectedActualDeclarationChecker
This test was checking errors *before* applying action, rather than
*after*, like all other QuickFix-tests do. This commit moves
errors-check after performing quick-fix action, and changes testdata:
- for most tests errors are simply gone (as quickfix usually fixes that
error)
- also, for implementMembersInActualClassNoExpectMember we add
'DISABLE-ERROR', similarly to
implementMembersInImplClassNonImplInheritor. This is needed because
'Implement Members'-fix created 'TODO'-calls, which are not resolved in
those tests due to the lack of stdlib. Previously, there were no errors
in this test exactly because file was checked *before* applying quickfix
(i.e. when there were no 'TODO()' in file)
Leonid Startsev