When a call is resolved to a classifier, only a single error message was
being used for multiple cases. This lead to confusion as the default
message may not be applicable to a given error case. Added additional
errors and messages to distinguish between these error cases.
#KT-57251 Fixed
We can avoid body resolution in some cases because it is more
than out contract is required
So ANNOTATIONS_ARGUMENTS_MAPPING should be enough for all
non-body parts of a declaration to return fully-resolved FirElement
Body parts incudes: body and default values
^KT-59266 Fixed
Fixes KTIJ-24609.
When completion happens outside the content root,
module kind should be detected by the original file.
Otherwise, module would not be the same because outside the content root,
each file has its own module.
Actual #findSourceFirSymbol also does search over originalDeclaration when present.
Added FirCompletionOutsideSourceRootTest in IJ monorepo
Previously the argument type was being used for the actual type error
display. However, safe-call arguments are unwrapped which causes
nullable types to be displayed as non-null. Change to use the actual
type provided by the diagnostic instead of extracting the type from
the argument.
#KT-58844 Fixed
`getReturnTypeForKtDeclaration` is called by UAST on probably compiled declarations.
In order to avoid redundant decompilation + building raw FIR + resolve,
let's delegate to deserialized FIR which is already prepared in stubs
Fixes KTIJ-24810
When `findSourceNonLocalFirDeclaration` is called on non-physical property accessor e.g.,
during completion, then traverse tree should allow drilling into FirProperty;
otherwise, no FIR would be found
In case of broken code e.g., duplicated classes provider would return first class,
though we definitely need some code insight in this case
at least to add navigation fixes, etc.
Similar to this, a file copy is created during completion,
where additional elements might appear and we need to search for them.
Added test cases for duplicated classes.
Otherwise, if fir was requested with non-physical element
inside existing analysis session (not on-air, e.g.,
`FirPositionCompletionContextDetector#analyzeInContext` with
`FirSimpleParameterPositionContext`) all consequent requests
would return fir with that non-physical source,
which might be already invalidated.
On-air sessions should be protected from invalidation problem but some clients
might expect original elements anyway and in this case, it would be
impossible to retrieve correct fir for them.
In order to find parameters, allow to traverse tree till functions.
To make sure all possible types are resolved and any additional errors
are reported, resolve children of function calls using independent
resolution mode when the callee reference is an error.
#KT-59041 Fixed
CompileTimeConstantProvider could receive a reference expression,
whose grandparent is KtTypeReference (seen that in UAST inspection).
FIR would not contain anything explicit for this reference,
FirResolvedTypeRef would be received as the nearest parent.
Of course, in this case, there could be no compile time constant anyway.
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59243 Fixed
^KTIJ-25412
Update equivalence checks for light accessor methods and light fields
to make them equivalent if they share the same underlying property.
Follow the `kotlinOrigin` declaration:
even if there is a property accessor,
use property declaration.
There are SOE exceptions caused by the fact that `getOrBuildFir` can
return a FIR declaration for the parent PSI. I wasn't able to reproduce
it locally, but this commit should prevent such problems by using
`getOrBuildFirSafe` with explicit type specification
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59240 Fixed
See the test data.
ISE happened because at some point after incomplete `getValue` resolution
of `a` property, we updated in the `transformAccessors` the property type
to the `Variable(Y)` type and then used it as a 3rd argument for
`setValue` call which is incorrect because the variable belongs
to a different constraint system (from `getValue`).
Mostly, the fix is just a repeating K1 behavior, namely postponing
`setValue` resolution until delegate inference is completed.
^KT-59066 Fixed
Ilya Kirillov