This origin was set somewhat arbitrarily.
It actually only makes sense for `IrCall`s to property getters.
There were no places in lowerings that checked `IrGetField` expressions
for this origin value.
^KT-62500 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
`allowNonCachedDeclarations` mode allows referring source declaration which
does not belong to the set of sources passed to fir2ir (e.g. for debugger
support). So if code refers to such declaration, fir2ir creates symbol
for it but not the IR declaration itself
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
Backend requires annotation constructors to be fully resolved for the
'IrConst' default value lowering. However, in the IDE there is usually
no need in complete annotation class resolution.
^KTIJ-27061 Fixed
FirDeclarationsResolveTransformer.transformSimpleFunction() performs
proper local function analysis only if the parent is properly set.
^KTIJ-26608 Fixed
In complex projects, there might be several library copies (with the
same or different versions). As there is no way to build a reliable
dependency graph between libraries, a project library depends on all
other libraries. As a result, there might be several declarations in the
classpath with the same name and signature.
Normally, K2 issues a 'resolution ambiguity' error on calls to such
libraries. It is acceptable for resolution, as resolution errors are
never shown in the library code. However, the backend, to which
'evaluate expression' needs to pass FIR afterwards, is not designed for
compiling ambiguous (and non-completed) calls.
Currently, the test files are only analyzed as source code, and present
errors do not affect code fragment analysis. In the following commits,
however, the test files will be compiled to test code fragment
analysis against library sources.
As 'FirCodeFragments' are converted to IR independently of its context,
in some cases duplicate (and not quite correct) symbols for local
classes and functions are created.
Until properly fixed in fir2ir, here we replace such duplicates with
original symbols.
In the old JVM backend, local functions were compiled as JVM classes,
so there were an instance to pass around. Today, they are compiled to
static functions in the containing class/facade, and calls to them
compile natively.
Alexander Udalov