They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
This commit changes the behavior of KT-59138 effectively declining it in 2.0.
However, we plan to implement KT-59138 behavior under a feature
flag in 2.0 (see KT-66447), and switch this feature on version 2.x.
Also, this commit implements the LC resolution about postponing
KT-57014 change. We don't have KT-57014 described behavior in 2.0 anymore.
However, we plan to implement a deprecation warning here, see KT-65578.
After this commit, 6 diagnostic tests become incorrectly broken:
- 5 tests from PurelyImplementedCollection group
- a test platformTypes/nullableTypeArgument.kt
This commit also breaks currently fixed-in-k2 KT-50134
(it is fixed again in the following commits),
as well as KT-58933 (it will remain not fixed till we enable KT-59138
behavior again).
#KT-65596 In Progress
#KT-57014 In Progress
#KT-58933 Submitted
This fixes some cases where we infer some type variable inside one
of the branches to Nothing instead of the expected type because Nothing
appeared in some other branch.
Specifically, we add an equality instead of a subtype constraint during
completion of calls to synthetic functions for if/when, try and !!.
We don't do it when the call contains a (possibly nested) elvis or is
inside the RHS of an assignment.
Otherwise, we would prevent some smart-casts.
#KT-65882 Fixed
Before this commit, the expect-actual resolver could find expects in
regular dependencies
Note: The appeared `VIRTUAL_MEMBER_HIDDEN` in
compiler/fir/analysis-tests/testData/resolveWithStdlib/multiModule/FakeOverrides.kt
isn't caused by my change. It's caused by fixing the testData dependency
syntax notation.
The testData improperly used regular dependency syntax notation, while
it should have been using dependsOn
Before:
Regular dependency syntax notation
// MODULE: androidMain(commonMain)
After:
dependsOn dependency syntax notation
// MODULE: androidMain()()(commonMain)
In some cases we transform flexible type into non-flexible during
enhancement, but don't add `@EnhancedNullability` attribute to them,
which breaks consistency with K1 on IR level
This commit fixes it
^KT-65302
A class can inherit two declarations that are compatible from the
overridability standpoint and are therefore combined to a non-trivial
intersection.
At the same time, the class can declare a member declaration that
only overrides one of the intersection's members.
In this case, we break up the intersection and only add the overridden
parts to the declared member's direct overridden list.
If the class doesn't override the intersection, it exists as
intersection override, like before.
#KT-65487 Fixed
Even though SO may not be correct
overrides sometimes, it feels more
natural to treat fake overrides as...
well, "overrides". And without it
we'd need to make the code in
`FirOverrideChecker` less intuitive.
We drop Kotlin function 'remove' or 'getOrDefault' from JvmMappedScope,
if it has platform-dependent annotation, and the bound Java class scope
does not contain a function with the same signature.
#KT-57268 Fixed
The primary constructor of a class needs to be the first subgraph of the
class control-flow graph. Based on the Kotlin specification, class
initialization order goes first primary constructor, in-place
declarations (properties and init blocks), and then secondary
constructors. If the class doesn't have a primary constructor, then it
is just skipped in the order.
Unfortunately, the class control-flow graph had in-place declarations
first and then all constructors. Instead, we should treat the primary
constructor as the first in-place declaration, and then continue with
the existing processing as secondary constructors. This will guarantee
that super constructor calls have the correct property initialization
information.
^KT-65093 Fixed
At the moment, SubclassOptInRequired is marked with the
ExperimentalSubclassOptIn annotation. However, it does not work
as expected due to a missing opt-in error. To use SubclassOptInRequired,
an explicit opt-in is necessary because SubclassOptInRequired is an
unstable feature now.
^KT-64739
There might be several pathes out from the function from CFG point of view:
- normal execution path
- exceptional execution path
For verification of callsInPlace contract it's needed to check only
the normal path
^KT-63414 Fixed
There are many complications with the current design of passing data
from within in-place lambdas to surrounding code. Solving these
complications will involve more time to investigation than is available
within the K2 release. So we are disabling passing type statement
information from lambdas for the time being until more time can be
devoted to a more complete solution.
^KT-60958 Fixed
^KT-63530 Fixed
Previously, there was a contract that each callable symbol in the chain
of `processDirectOverriddenWithBaseScope` will be unique. And if some
symbol is accessible from multiple scopes, then only last of them will
be returned as a component of `MemberWithScope`. So there actually was
no such thing as "pair of two different MemberWithScope with the same
symbol and different scopes"
After the change of `processDirectOverriddenWithBaseScope` contract (see
previous commits) each scope returns `MemberWithScope` for some symbol
with the previous scope in the hierarchy even if it contains the same
symbol as the current scope
So now scope is actually a part of `MemberWithScope`, which should be
considered as part of equality. Otherwise, we can skip some part of
the overridden hierarchy, because we will start to consider symbol as
visited after its first occurrence (in opposite to the previous behavior,
when only the last scope was returned)
Currently, PROPERTY_WITH_NO_TYPE_NO_INITIALIZER is reported for local
variables, but not reported for member or top-level properties. Add a
check to the common `checkPropertyInitializer` for when a property
type cannot be determined from the getter.
This also corrects a K1 versus K2 inconsistency, where K2 would allow
blocks from getters to determine property type instead of only allowing
expression bodies.
^KT-59935 Fixed
^KT-60117 Fixed
^KT-60123 Fixed
It's effectively a breaking change (^KT-62558)
K2 assigns flexible type to all static fields (from Java) and, for example,
`String? becomes String unlike K1. It affects IR signature generating.
That's why signature dump is disabled for some tests.
^KT-57811 Fixed
^KT-61786 Fixed
This uses the same approach as
INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION where we use a visitor
to find a call to a symbol that contains the type variable in question.
#KT-56140 Fixed
This is needed because in order to figure out which declarations are
visible from anonymous objects in terms of overridability (see
`FirVisibilityChecker.isVisibleForOverriding`), we need to get the
package name of that anonymous object, because there's package-private
visibility on JVM.
#KT-62017 Fixed
See the comment at updateSubstitutedMemberIfReceiverContainsTypeVariable
It became necessary after delegate inference is rewritten, since before
that happened, stub types were being left there and FIR2IR handled
them accidentally properly because stub types are equal to anything.
But that wasn't really correct even there because stub types are not
intended to leak out of the FIR
^KT-61060
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
UncaughtExceptionPath edges are used to influence smart-casting within
catch and finally blocks. Previously these edges were added from every
node which could throw an exception. But only assignment nodes influence
smart-casts by resetting inference back to some less specific type.
Therefore, instead of tracking every possible node which could throw an
exception - even though almost every statement node can - only add edges
from assignment nodes to catch and finally blocks. This fixes many
missing exception cases and also reduces the total number of incoming
edges to catch and finally blocks.
#KT-56872 Fixed
In order to properly analyze top-level property initialization, a
control-flow graph must be created for FirFiles. This change adds the
foundation for the file CFG and updates body resolve to create the CFG.
Checking the CFG for proper initialization is separated into a following
change to ease code review.
KT-56683
Kirill Rakhman