... when the expected type is not a function type.
Instead set it to a new type variable.
This fixes a bunch of false negative CANNOT_INFER_PARAMETER_TYPE.
#KT-59882 Fixed
`testIntersectionOfPrimitiveBasedFunctions`
is fine, because we deprecate this
already in ^KT-63243.
`CANNOT_INFER_VISIBILITY` is
positioned as `DECLARATION_NAME`,
just in case we decide for
some reason that we do want to
report it along with
`MANY_*_NOT_IMPLEMENTED`. In that
case, we'd get a problem that
their bounds overlap, but not
completely contain one another.
^KT-63741 Fixed
^KT-59400 Fixed
Local properties defined within the body of a do-while loop can be used
in the condition of the loop. However, use of a `continue` may mean the
property isn't always initialized, even if it is initialized when it is
defined. So while a local property may be within scope and has an
initializer, this doesn't always mean that the property is initialized.
As such, properties that are defined within a do-while loop and also
used in the condition of the same do-while loop should be tracked. Then,
these properties should still be checked for proper initialization even
if they have an initializer.
^KT-64872 Fixed
Handle case with FirField properly. Previously the code was returning
STABLE_VALUE in that case.
Note that in fact the changed 'when' branch expects only FirJavaField,
as FirFieldImpl should be handled by FirBackingFieldSymbol-check at
the beginning of the method. However, it is impossible to refer to
FirJavaField directly due to module visibility
Enumerate all cases more carefully via exhaustive 'when',
it's more readable and will prevent potential issues in future in case
more subclasses are added.
^KT-58279 Fixed
Postponed lambdas introduce a host of challenges in data-flow analysis.
While inheriting type statements was disabled while these challenges are
being considered, we must still copy type statements from non-postponed
lambda edges. It seems the same is true for implications.
Implications are copied from previous flows when there is only a single
previous flow. That is because it never seemed to be required based on
test results. However, a recent test case revealed that copying is
required when there are multiple previous flows, but only one flow is
from a non-postponed-lambda node.
Combining implications from multiple non-postponed-lambda nodes did not
have an impact on test results, so until such a test case can be
created, the overhead of calculating common implications from multiple
flows will be avoided.
^KT-63351 Fixed
This reverts commit bb6f466162.
Reverting the fix for KT-57417 as it causes failures in IntelliJ and
Space projects. May reintroduce fix after failures are investigated and
resolved.
When a property is implemented via class delegation, it should be
considered unstable for smart-casting. This is because it is unknown
what kind of stability the underlying class delegate property has. It
could be a stable property, or it could be implemented via a custom
getter and unstable.
^KT-57417 Fixed
FirConstExpression is usually confused with "constant" calculations,
while in fact, it just denotes a simple literal expression
and `1 + 1` isn't represented by a FirConstExpression.
^KT-64314 Fixed
`FirDeserializedEnumAccessExpression` requires session to build proper
reference, so it's important to have it in all utilities, which may
pass this element as input
^KT-64975
This is needed to gain access to providers functionality in those
utilities, which is important for support of FirDeserializedEnumAccessExpression
node (see later commits)
^KT-64975
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
It's expected to partially mimic the behavior of what
previously was called builder inference, but with more clear contracts
(documentation is in progress, though)
See a lot of fixed issues in the later commits with test data,
especially [red-to-green]
^KT-59791 In Progress
Before this change `ARGUMENT_TYPE_MISMATCH` would complain that
`Y` "is not a subtype of" `Inv<Y>`, because the function would only
check immediate bounds of the type parameter `Y`. `chosenSupertype`
would be `X`, not `Inv<out kotlin/String>`.
^KT-60056
This is required for the following commit where candidates from the
original scope in presence of smart cast will not be ignored if they're
the same symbol.
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
'ContextCollector' is used for computing context of 'FirCodeFragment's.
Code fragments themselves might contain additional smart cast operations
that modify the context receiver stack.
^KT-63056 Fixed
Pass constraint errors from the integration system into a candidate to
make sure it is reported later.
Related to KT-59426, KT-59437, KT-53749
#KT-55168 Submitted
This commit does two things:
- prioritize type parameter scopes against static scopes in body resolve
(effectively it's a revert of KT-58028 fix)
- consider type parameters as inapplicable callable, so during callable
resolve we can go up the tower and still resolve to static scope
This allows both KT-58028 and KT-63377 to work properly
#KT-63377 Fixed
If the right-hand side of an equality comparison contains an assignment
to the variable used in the left-hand side, then implications about the
equality comparison within data-flow analysis cannot be applied, as the
value of the variable will be different after the comparison.
^KT-55096 Fixed
This fixes a false positive OUTER_CLASS_ARGUMENTS_REQUIRED when
referring to an inner class of a supertype that is extended using a
typealias.
#KT-62099 Fixed
Kirill Rakhman