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
Preliminary refactor in preparation for the implementation details to
fix KT-56888. This change makes it so alternate data flows can be
created and maintained through CFGNodes. This change was separated and
created first to aid in the code review process.
Jump edge targets are maintained globally within the CFG builder and are
added indiscriminately to `finally` exit nodes. This means that a
`finally` exit node could have a jump edge added which doesn't match how
the `finally` block was entered. Make sure edges are only added to the
exit node if they also exist on the enter node.
#KT-60723 Fixed
This commit prevents language version increase due to bootstrapping
problems. Compiler version X attempts to build the project with the
current version X+1 -> warning about progressive mode cannot be enabled ->
error due to -Werror -> build failure.
By ignoring type parameters. Since type parameters in annotations are a
very limited feature, their sole use is to be able to specify them as
KClass argument: annotation class Foo<T: Any>(val bar: KClass<T>).
Since we can encounter type param only as a KClass type argument (and
never as a property type), simple approach of ignoring them works fine.
In that case, since we simply copy property types to synthetic
implementation class, its properties in IR start look like this:
annotation class FooImpl(override val bar: KClass<T of Foo>). This IR
seems to be not completely correct, since FooImpl.bar type contains T of
Foo param, which is out of its scope. However, so far I didn't
encounter any problems with this during testing and after MR discussion
this approach has been considered possible.
#KT-59558 Fixed
#KT-59036 Fixed
They were needed as a temporary migration in scope of KT-58587
Now the bootstrap and IDE include KT-58587 patch, so @Suppress and
`final` are no longer needed
Refactoring in 4986cb14 introduced an unintentional behavior change:
private symbols are now findable in symbol table with lookup by
signature.
Unfortunately, this is not correct - private symbol signature might not
be unique (or at least was sometimes not unique in older compiler
versions), which leads to crashes on deserializing corresponding klib.
This commit restores old behavior.
^KT-60616
Temporary solution for K1 - see comments in the code
it seems that a scenario reproduced in the MainKtsTest.testKt48812
wasn't covered with analogous changes before.
And it wasn't detected while main-kts tests weren't a part of the
K1 scripting tests.
The test is fixed now, and testing of main-kts is restored.
the script declarations are considered public, at least because they
can be reused from another script then used with the `importedScripts`
configuration property. It also improves the compatibility with K1
scripting.
and base class handling:
Since in K2 we do not distinguish between script arguments taken from
the base class and provided properties, we need this extra functionality
to preserve the argument order of K1 scripts.
This is a temporary measure, since we're going to deprecate base class
usage at some point (KT-60449), so the relevant constructor arguments
should disappear too.
UNNECESSARY_SAFE_CALL is a warning,
UNEXPECTED_SAFE_CALL is an error, thus
it's a breaking change.
Also see KT-60695.
^KT-59860 Fixed
Merge-request: KT-MR-11210
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
This change is necessary in order to make `FirElement` abstract class. To do it we need to remove all `accept` and `transform` methods from fir interfaces. So we have to make sure that all fir element implementations have their `accept` and `transform` implementations in their super classes. In particular this change makes 'accept' and 'transform' methods in `FirConstructedClassTypeParameterRef` and `FirConstructedClassTypeParameterRef` base classes.
This change is necessary in order to make `FirElement` abstract class. To do it we need to remove all `accept` and `transform` methods from fir interfaces. So we have to make sure that all fir element implementations have their `accept` and `transform` implementations in their super classes. In particular this change makes `FirImport` abstract class in order to preserve `accept` and `transform` methods after removing them from fir interfaces.
Ivan Kylchik