10 Commits

Author SHA1 Message Date
Brian Norman 0e2b3ce845 [FIR] Create alternate DFA flows through finally blocks
Entering a `finally` block can happen from many different places:
through an exception, a jump, or normal exit from the `try` block. When
in the `finally` block, all DFA flows must be merged to have correct
smart casting. However, after the `finally` block, if exiting normally
or because of a jump, the combined flow from within the `finally` block
should not be used, but rather an alternate flow which combines the
correct flows from before the `finally` block.

```
try {
    str as String // Potential cast exception
} finally {
    str.length // Shouldn`t be resolved
}
str.length // Should be resolved
```

When building DFA flows, track the start of possible alternate flows,
and continue building them until they end. Both of these situations are
now marked on CFGNodes via interfaces.

When building the default DFA flow, and the source node is the end node
of alternate flows, attempt to use the alternate flow with the same edge
label instead of the default flow of the source node.

#KT-56888 Fixed
2023-07-27 13:05:58 +00:00
Nikolay Lunyak 7541732752 [FIR] Fix TEST SPEC tests
Ensure the test data contents for both the frontends
are identical. This is needed for proper analysis of
K2-differences.
2023-06-19 07:40:15 +00:00
Victor Petukhov 42e71f8c53 Remove explicit enabling the new type inference from test data 2022-07-22 16:03:52 +00:00
Tianyu Geng 4726dcce40 FIR DFA: smartcast variable to Nothing? on null assignment
In order to make resolution still work for members not available from
`Nothing`, we track the type without `Nothing?` and use that for
resolution instead.
2021-08-06 22:57:15 +03:00
Dmitriy Novozhilov 469252f6b4 [FIR] Don't create smartcast node if smartcasted type is equal to original type 2021-02-20 10:23:33 +03:00
Mikhail Glukhikh 7d4eaefd36 FIR: report UNSAFE_CALL on dot when possible 2021-01-29 16:55:26 +03:00
Jinseong Jeon e72ddbcbfe FIR checker: differentiate UNSAFE_CALL from INAPPLICABLE_CANDIDATE
To do so, inside the root cause of inapplicable candidate errors,
we will record expected/actual type of receiver, if any.
That will help identifying inapplicable calls on nullable receiver.
2021-01-29 16:54:23 +03:00
Jinseong Jeon b3b09ea9b7 FIR: adjust spec testData after DFA changes:
* recording type statements for null assignments
* element-wise join by default
2020-11-04 16:35:42 +03:00
anastasiia.spaseeva 9d862aaa1d [Spec tests] Remove spec info from fir tests 2020-05-26 17:27:06 +03:00
Denis Zharkov 0d34299b7a FIR: Adjust testData for spec tests: dfa 2020-04-21 09:52:52 +03:00