In DeserializedClassDescriptor and MemberDeserializer, only the
`contextReceiverTypeList` field was used, and not
`contextReceiverTypeIdList` which is used when `-Xuse-type-table` is
enabled. The convention is to use a bunch of utilities declared in
`protoTypeTableUtil.kt` which deal with both methods of reading types.
Also, simplify the deserialization code in FIR (which was correct for
some reason).
Replace loading the whole world IR with loading only exported (reachable) IR.
For that purpose the direct and inverse dependency graph is used.
It is stored in a cache directory and the cache updater keeps it up to date.
If after loading it is found that other files must be also implicitly rebuilt
(see rebuilt reasons below), IR for that files also will be loaded.
This algorithm repeats until the number of implicitly rebuilt files is not 0.
More rebuilt reasons (dirty state) have been added:
- added file: this is a new file;
- modified ir: ir of the file has been updated;
- updated exports: exports from the file have been added or removed
(e.g. a function has been used from another file);
- updated inline imports: imported inline function has been modified
(transitively);
- removed inverse depends: a dependent file has been removed;
- removed direct depends: a dependency file has been removed;
- removed file: this file has been removed.
Incremental cache tests has been refactored:
- The supporting of all rebuilt reasons (dirty states) has been added;
- New file name format "*.$suffix.kt" for the test steps has been allowed,
so the syntax highlight works now;
- Explicit stdlib dependency usage has been removed.
The analyzer can now handle the case where a parameter containing an
inline lambda is overwritten with something else. The local variable
remapper still can't handle that, and KT-51950 is caused by a deeper
underlying issue (the slot should't get overwritten in the first place),
but at least the problem is more visible now:
>java.lang.RuntimeException: Trying to access skipped parameter:
> Lkotlin/jvm/functions/Function1; at 2
ClassCodegen bails before generating code if the filter supplied to
the GenerationState rejects it based on the containing file or class
declaration itself.
* wrong method was called from FirDataFlowAnalyzer.exitFunctionCall;
* map from function to affected properties should be keyed by symbol,
not FirFunction, as the latter may change;
* arguments of `return` and assignment statements should be visited,
as they may contain lambdas.
This is what Java 15+ does, and it permits accessing captured type
parameters via reflection. The alternative is to emit generic signatures
on the lambda methods, but that was disabled and I have no clue why.
^KT-52417 Fixed
Mikhail Glukhikh