Intersections for interfaces and generic interfaces work differently.
`FirIntersectionCallableSymbol.getNonSubsumedOverriddenSymbols()`
does not retrieve the original symbol for a symbol inherited from
generic interfaces.
The patch explicitly obtains original symbols if they exist.
^KT-65216 Fixed
PendingDiagnosticsCollectorWithSuppress is a special diagnostic collector,
which aggregates diagnostics reported during checking of some specific
element before actually reporting them, so its workflow looks like this:
- start checking some element;
- all reported diagnostics go to `pendingDiagnosticsByFilePath` map;
- all checkers done their jobs;
- diagnostics from `pendingDiagnosticsByFilePath` go to the resulting map
of all diagnostics (not all, only ones which lay inside the checked
according to PSI);
- processed diagnostics removed from `pendingDiagnosticsByFilePath`
This approach works fine, but there was one problem with it:
`pendingDiagnosticsByFilePath` is not just a list of diagnostic, but
map of lists, grouped by the containing file. And only those lists
actually get cleared. But if some list was completely emptied, it still
remained in the original `pendingDiagnosticsByFilePath` map
This led to the performance problem in case, where there are no actual
diagnostics in the `pendingDiagnosticsByFilePath`, but the map itself
is not empty but full of empty lists. So collector iterated over this
map on each visiting of each element
And after KT-58881 this problem was uncovered, as number of visits of
elements was twiced (because now we iterate over the whole tree twice,
with Common and Platform checkers)
The fix is quite trivial -- if some list in `pendingDiagnosticsByFilePath`
becomes empty, remove it from the map
^KT-65579 Fixed
The Firebase TestLab requires those properties to be present,
otherwise fails with verification errors.
These properties are specific to the Xcode installation or
toolchain used, and should be retrieved from it, not hardcoded.
See also KT-65601.
Part of the ^KT-58928
Merge-request: KT-MR-13964
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
Some FIR checkers were placed into the wrong directories either
by accident or minor oversight. This commit contains fixes
for such cases that were made during work on an internal KCCQA utility
to simplify its workings.
This commit is expected not to affect much (if anything).
In this way, we can be sure that all nested declarations will be fully
resolved before the outer one. As an example, we had a workaround for
file diagnostics as its `FileStructure` element resolves the file only
to `IMPORTS` phase yet.
Also, this commit probably should improve the performance of highlighting
as we will trigger the resolution from bottom to top while other
highlighting passes will iterate from top to bottom.
^KT-65562
The root cause of the exception is that we missed such an element, and
it led to unresolved declaration during iteration over file declarations
^KT-65562 Fixed
- test task will run JVM and JS backend tests; called by CI
- nativeTest will run Native backend tests; called by CI
- check will run all backends tests; called locally;
- :nativeCompilerUnitTest are unit tests on K/N compiler.
- :nativeCompilerTest are tests using K/N compiler and should be run in
many different compilation modes that K/N supports.
Limiting spawned by our Gradle integrations tests Gradle daemons maximum
heap size to 1g helps to reduce memory pressure on the system when
running these tests in parallel. Especially it is actual for our CI
agents.
^KT-65701 Fixed
Phase COMPILER_REQUIRED_ANNOTATIONS causes errors in the kotlinx serialization tests:
org.jetbrains.kotlin.fir.symbols.FirLazyResolveContractViolationException: `lazyResolveToPhase(COMPILER_REQUIRED_ANNOTATIONS)` cannot be called from a transformer with a phase COMPILER_REQUIRED_ANNOTATIONS.
`lazyResolveToPhase` can be called only from a transformer with a phase which is strictly greater than a requested phase;
i.e., `lazyResolveToPhase(A)` may be only called from a lazy transformer with a phase B, where A < B. This is a contract of lazy resolve
If a parameterized type ref is passed during the `FirSupertypeGenerationExtension.TypeResolveService#resolveUserType` call, the `WRONG_NUMBER_OF_TYPE_ARGUMENTS` error occurs.
Added inspections to check:
- custom serializer on class has as many parameters in primary constructor as the serializable class of type arguments
- all parameters in custom serializer has `KSerializer` type
- property in serializable class not parametrized by type parameter
- custom serializer on property of serializable class have no parameters in primary constructor
Before this commit, fir f/o builder was inconsistently
disabled in some places, while it should work only for lazy declarations
Attempt to use it for non-lazy declarations, without maintaining
invariant, that it would also be used for super classes
led to unpredictable results.
This commit introduces opt-in, and marks all related API to three types
* Propagate error to user
* Fine to use, as it's checked if ir f/o builder is enabled
* Fine to use, as it is definitely a lazy class.
Several cases of missing checks was fixed.
^KT-65707
Dmitrii Gridin