If only regular kotlin .kt (and .java) files are compiled, do not
register file extensions that may come from discovered script
definitions. Since the discovery is lazy by itself, this should
skip jars processing for regular compilation scenarios without scripts.
#KT-47816 fixed
- process command line properly when plugin is autoloaded
- add and fix options to disable definitions autoloading and discovery
- cleanup unused code
(partial test is added to "avoid definitions discovery" commit)
For FE 1.0, we just change super qualifier symbol to
base class, if it's possible.
For FIR, we introduce using of super qualifier symbols for
field accesses and repeat FE 1.0 behavior here.
#KT-49507 Fixed
For example:
foo(
// `if` joins A & B
if (condition)
run { ... } // A
else
run { ... }, // B
run { ... } // C
) // `foo` unifies `A & B` and `C`, so if it is not resolved itself,
// further `if`s, `when`s, safe calls outside it, etc. continue
// building the correct type predicate until the next completed
// call.
^KT-44512 Fixed
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).
* 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
- Get rid of SPECIAL mode (just left REGULAR and class-related instead)
- Clear naming
- Restore contexts after lambda/callable reference are processed
The test has been failing before this change because after
callable reference is resolved, its tower data context has been left
erroneously in the SPECIAL-related entry
If we want to analyse some function's call, we need to know about its
contracts, otherwise resolving the following code would be broken.
Computing return type of function is a prerequisite to using it in any
sensible way, so it's the best place to resolve it to CONTRACTS
KT-50733
Using `ownerLookupTag` might be wrong in case of private constuctors
of inner classes: their owner is an Inner class, but expected
dispach receiver is Outer
Ivan Kochurkin