When we check overrides from IDE, we need to check argument types for subtyping.
When checking for subtyping, we need type parameters declared
in defining classes to be resolved to TYPES phase
and super types to be resolved to SUPER_TYPES phase.
Otherwise, they will be resolved to RAW_FIR and subtyping will throw
"ISE Expected FirResolvedTypeRef with ConeKotlinType but was FirUserTypeRefImpl"
Previously, composed checker passes the `allXXX` flavor of checkers to
each category of checkrs. This makes the composed checkers
non-transparent: behavior changes after composing. In addition, nested
composing would create redundant checkers.
As a result, some checkers registered in the IDE mode
(org.jetbrains.kotlin.idea.fir.low.level.api.diagnostics.AbstractFirIdeDiagnosticsCollector)
are not invoked with the FIR plugin.
This change does two things:
1. pass on checkers to composed checkers without combining
2. use combined checkers in DeclarationCheckersDiagnosticComponent and
ExpressionCheckersDiagnosticComponent
These tasks did copy all files from build to build/nativelibs, thus
causing up-to-date checks to fail, and native libs and temporary build
files to be accumulated in recursive directories like
nativelibs/nativelibs/... in both build dirs and dist.
Fix this by copying only relevant files.
GC implementation for testing purposes
* Only works for a single mutator
* Runs on the same thread as the mutator
* Runs every nth checkpoint and after every m bytes are allocated
* Runs finalizers after sweeping on the mutator thread.
Specifically, the report the following 4 errors.
* NON_VARARG_SPREAD
* ARGUMENT_PASSED_TWICE
* TOO_MANY_ARGUMENTS
* NO_VALUE_FOR_PARAMETER
Also added/updated the following position strategies.
* NAME_OF_NAMED_ARGUMENT
* VALUE_ARGUMENTS
Currently VAL_REASSIGNMENT are only reported on direct assignments.
Reassignments in the form of, for example, `+=` are reported as
`VARIABLE_EXPECTED`, which differs from FE1.0.
Commonize (in terms of TypeSystemCommonBackendContext implementations
for KotlinType/IrType) code that computes optimal TypeMappingMode to
apply to different positions where inline class types can be present.
KotlinTypeMapper.mapInlineClassTypeAsDeclaration and
mapUnderlyingTypeOfInlineClassType invoked mapType which is defined in
descriptorBasedTypeSignatureMapping.kt and works on KotlinType.
It didn't lead to any problems, other than the fact that we were
constructing IrBasedClassDescriptor in JVM IR, and then KotlinType to
pass it to mapType, on each call to StackValue.boxInlineClass or
unboxInlineClass, which seems wasteful.
Instead of this, refactor these utilities to use type markers instead,
pass IrType and IrTypeMapper directly from JVM IR, and move the "static
type mapper" logic (which is used only in the old backend) out of
KotlinTypeMapper.
Jinseong Jeon