`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
The root cause of the exception is that we missed such an element, and
it led to unresolved declaration during iteration over file declarations
^KT-65562 Fixed
Suggest removing explicit type arguments when the upper bound is a
captured type since the only way to satisfy the upper bounds is
by letting the type variable be inferred to its bound.
#KT-65681 Fixed
The diagnostic target source element
type was changed to prevent crash due
to `checkPsiTypeConsistency()` in
`duplicateParameterNameSimplified.fir.kt`
^KT-65584
- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
This only affects delegation operators as well as the for-loop-related
next and hasNext operators.
All the other operators worked correctly before.
In K2, the previously mentioned operator calls will be flagged with a
deprecation error and will become and error in 2.1.
#KT-59782 Fixed
Now we have only one FirDesignation instead of `FirDesignation`,
`FirDesignationWithFile` and `FirDesignationWithScript`
This allows us to unify situations with `FirFile` and `FirScript`
in the path and unbind from `FirRegularClass`.
This commit only refactors code, the semantic is still the same yet
^KT-65345
Before, auto-completion was based on on-air resolve, and
'FirTowerDataContext' was computed once, during creation of the
dependent analysis session (with using 'FirTowerDataContextCollector').
This allowed to return the context almost instantly, no matter how many
completion candidates there were.
Dangling file resolution doesn't use 'FirTowerDataContextCollector', as
now there is more precise 'ContextCollector'. However,
'ContextCollector' doesn't cache results by itself, and, if asked, it
will compute the same context over and over again. This exact happened
with extension applicability checker.
The optimized implementation maintains a checker object which caches the
computed context. The old end-point is left to give the IDE plugin time
to adapt to the change.
^KTIJ-28445
This diagnostic is reported on an explicitly-declared function which
overrides a regular Java function with the same signature as a hidden
one from the same scope.
#KT-64846 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
When encountering multiple available same named types,
resolve all of them together with corresponding extensions.
This aligns well with the current resolve behavior of classes
with the same name (see `SameNameClassesFromStarImports.kt`)
Also, add extra test for resolving the ambiguous type without
the extension function. The behavior is the same - resolve to the
both classes.
The solution is not complete, since resolution of KDocs is not
fully specified and is rather tricky.
Many more corner cases are to be expected.
This solution should at least give some groundwork for the future
improvements/fixes of the resolver.
^KT-62695 Fixed
It's a part of implementation; it will be required to properly navigate
from resolved extension function to its receiver type, since receiver
type cannot be properly inferred from the function symbol itself
Make sure that, when ambiguous, both the package
and the callable/class/property are resolved from
KDoc reference.
Do a slight refactoring of `KDocReferenceResolver`
This behavior is also true for K1
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
Anna Kozlova