Before this commit, we allowed access to outer class type parameters
during resolve of type parameter bounds of a nested class.
In fact, outer type parameters are accessible in this situation
only if it's an inner class (or a local class).
This commit forbids such a usage. In the earlier fix of KT-57209
the same was done for regular type reference resolve.
#KT-61459 Fixed
#KT-61959 Fixed
'DFANode' is not created for certain elements, such as types or
references. Before the change, only the target element itself was
queried for DFA, making the 'ContextCollector' return an empty map of
smart casts.
^KTIJ-26973 Fixed
Before, 'KtCodeFragment's were analyzed as a part of their context
session. Now, a separate session is created for each code fragment,
and the LLLibraryScopeAwareCallConflictResolverFactory registration
moved there.
Before, `KtCodeFragment`/`FirCodeFragment` was analyzed as a part of
its context `KtModule`. This has the following complications:
- In non-source sessions, diagnostic reporting is globally disabled.
For code fragments, however, checking the code before passing it to
the backend is essential.
- Special treatment for call ambiguities in libraries
(`LLLibraryScopeAwareCallConflictResolverFactory`) becomes complicated
as the conflict resolver has to be applied to a library module.
- `KtCodeFragment`s usually have a shorter lifetime than their own
context. Caching may potentially be implemented differently for them.
^KT-61783 Fixed
Primary constructors can't have any contracts.
This change also should improve memory consumption because we will
less frequently calculate bodies.
^KT-55750
FirContractResolveTransformer under the hood calls
```
if (property is FirSyntheticProperty) {
transformSimpleFunction(property.getter.delegate, data)
}
```,
so this leads to unsafe transformation of the original function
^KT-55750
Delegated properties can't have any contracts.
This change also should improve memory consumption because we will
less frequently calculate bodies.
^KT-55750
Legacy (current) contracts can exist only on functions with bodies.
This change also should improve memory consumption because we will
less frequently calculate bodies.
^KT-55750
In-block modifications are applicable only for FIR declarations with
fully resolved bodies. It can happen only during implicit type and body
phases. The implicit type phase probably is not applicable for our
particular case, but we will play safe because properties have a
complicated resolution logic, so it is hard to be sure that only body
phase will be enough.
Changes inside contracts are treated as out-of-block, so we can avoid
marker from this phase. Also, all mentioned calls inside bodies resolve
the corresponding declarations to the contract phase, so we will save a
lot with this optimization.
Q: Why in-block modification can be heavy?
A: In most cases this invalidation is pretty cheap because we have all
required information inside caches. But it is possible that we can
receive an in-block modification event for PSI without a corresponding
FIR element, or it is not yet fully resolved. In this case, for example,
we will do such redundant works as a raw FIR building or KtModule search
^KT-61842 Fixed
Ivan Kochurkin