Commit Graph

5 Commits

Author SHA1 Message Date
Simon Ogorodnik 82611ad124 FIR. BI: Fix stub type leakage in builder inference
Previously, updateTypeInBuilderInference was calling
updateTypeFromSmartcast to actually perform type update in
implicit receiver after stub types was inferred
Such action results in creation of following FIR:

FirSmartCastExpression(
    original=FQAE(FirImplicitThisReference, typeRef=R|Inv<Stub>|)
    typeRef=R|Inv<String>|
)

in receiver position during completion of calls

However, it wasn't the case in general situation due to
action of FirStubTypeTransformer, which, in turn visits and updates
type ref inside original expression, but only if there was at
least one call (that was completed) using that implicit receiver
As after such type update updateTypeFromSmartcast function does
nothing

Yet in situation, when there was only partially resolved calls
referencing that implicit receiver we actually create smart-cast
expression and don't update type

The change just removes usage of updateTypeFromSmartcast and
replaces is with direct type update
We still mutate state of implicit receiver, potentially
improperly, it should be addressed in future

^KT-54708
^KT-58365 Fixed
2023-05-04 12:46:28 +00:00
Dmitriy Novozhilov 7af43176ce [FIR] Add optin on API of updating type of receiver values. KT-54708 2022-11-03 08:30:09 +00:00
Victor Petukhov fa7809cd80 [FE] Remove BuilderInference annotation from tests 2022-06-21 15:01:56 +02:00
Victor Petukhov b8030ec1de [FIR] Substitute lambda implicit receivers with builder inference stub types
^KT-51988 Fixed
2022-05-09 12:38:38 +00:00
Victor Petukhov 6027c2a9aa [FE] Substitute fixed type variables with inferred stub types
Actually, a type variable might be fixed into a stub type. Such stub type should be substituted before sub calls completion

^KT-51988 Fixed
2022-05-09 12:38:37 +00:00