`x?.y != null` does not imply that `x != null` if e.g. an argument to
`y` has reassigned `x` in the meantime.
The same is true for `x == y` and `functionWithContract(x, y)`, but
those are somewhat harder to implement since there is no easy way to
find the last node of a certain argument.
^KT-55096
Second step for KT-52615
Get rid of PsiHandlingMode
Get rid of source in FirLazyBlock
Refactor lazy creation
Merge-request: KT-MR-7753
Merged-by: Egor Kulikov <Egor.Kulikov@jetbrains.com>
- The Java functions aren't recognized as candidates during the test
(`FULL_JDK` isn't helping), so I've replicated the tests with local
extension functions and confirmed that they uncover the same
exception.
- Call candidate collection sometimes provides candidate symbols to
`createConeSubstitutorFromTypeArguments` with fewer type parameters
than type arguments provided by `FirQualifiedAccess`, which lead to
an NPE. Because call candidates collected for the purposes of the
Analysis API are best-effort guesses, we can ignore the additional
type arguments.
^KTIJ-23373 fixed
^KTIJ-21506 fixed
For the following example:
```
fun foo(bar: Int) {
<expr>if (bar == 4) return "Four"
else return "Int"</expr>
}
```
AA FE1.0 `isUsedAsExpression` returns `false`.
Since the current AA FIR `isUsedAsExpression` returns `true` for the
above example, this commit fixes it.
- `toResolvedCallableSymbol`: cast defensively because
the resolved symbol might not be a callable symbol.
- `toKtCallInfo`: Check that the resolved symbol is actually callable.
^KTIJ-23003 fixed
- Ensure that typed equals parameter's type is a star projection of
corresponding inline class
- Make possible to declare typed equals that returns 'Nothing'
- Forbid type parameters in typed equals operator declaration
^KT-54909 fixed
^KT-54910 fixed
Review: https://jetbrains.team/p/kt/reviews/7690
Make findSourceFirDeclarationByExpression signature more specific.
`KtDeclaration` is an inheritor of `KtExpression`
`KtLambdaExpression` was changed to `KtFunctionLiteral` in
c24ad0ba51. I run analysis-api-fir tests
and ensured that `KtFunctionLiteral` appears in runtime instead of
`KtFunctionLiteral`
So `ktDeclaration` should be either `KtDeclaration` or
`KtFunctionLiteral`. But we don't need a KDoc for that because
`KtFunctionLiteral` is an inheritor of `KtDeclaration`, so type-system
already checks this invariant
Before, BODY_RESOLVE phase were used for them but status may be unresolved.
This caused CCE on accessing resolved status for such static enum members.
Now, those declarations are created with the status of owning enum as the status is taken from that class.
Before, no parent element was returned for an object literal inside a
private property initializer, as only the getter was considered as a
potential parent.
Relevant tests are added on the IDE side (see 'LightClassBehaviorTest').
See: compiler/testData/asJava/lightClasses/
AnnotatedParameterInInnerClassConstructor.kt
The muted tests don't work with the (KT-53371, KT-53519)-related
changes. During this test happens an attempt to access unresolved
annotations via CustomAnnotationTypeAttribute.
Discussion: KTIJ-23547
Otherwise, `transformPropertyAccessor` from
`FirDeclarationsResolveTransformerForArgumentAnnotations` is
never called
See:
- compiler/testData/asJava/ultraLightFacades/properties.kt
- analysis/analysis-api/testData/symbols/symbolByPsi/
contextReceivers/contextReceiversOnProperty.kt
Dmitriy Novozhilov