It's been changed because `getValue` might be not completed after
exiting from call transformation while contracts processing seems to be
working only with completed calls
^KT-61055 Related
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
The original Java checker has an early return in
case of `resultingDescriptor !is JavaClassConstructorDescriptor`.
It fires if the descriptor is
`TypeAliasConstructorDescriptor`, thus further
diagnostics are not reported.
To avoid collecting context which includes the implicit class receiver,
context for class header positions is collected before entering
the `context.withRegularClass` call
IllegalArgumentException: class
org.jetbrains.kotlin.psi.KtLambdaArgument is not a subtype of class
org.jetbrains.kotlin.psi.KtExpression for factory
TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM
was reported when TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM was
reported on a FirLambdaArgumentExpression, report it on its
`expression` instead.
#KT-60380 Fixed
Previously, If we had multiple overloads of the same function in the same file,
then `LLFirProvider.SymbolProvider.getTopLevelPropertySymbols`
might be called with multiple copies of the same `KtFile`,
thus providing multiple copies of the same `FirNamedFunctionSymbol`.
It might be reproduced when `LLFirCombinedKotlinSymbolProvider` is used
and if nobody accessed `LLFirProvider.SymbolProvider` without a context.
A wrong result with multiple duplicating symbols will be cached in this case.
The commit fixes KT-61683 as `ConeOverloadConflictResolver` prefers actuals over expects
only in a case of valid code when an actual has a single corresponding expect.
It was not true because of the bug; thus, the problem from KT-61683 arose.
^KT-61683 fixed
This name leads to inconsistency between FqName from stub and
FqName from ClassId.
The first one is `no_name_in_PSI_3d19d79d_1ba9_4cd0_b7f5_b46aa3cd5d40`
but the second one is `<no name provided>`.
We can't just replace SAFE_IDENTIFIER_FOR_NO_NAME to NO_NAME_PROVIDED
due to many places with unsafe logic inside type mapping.
^KTIJ-26848 Fixed
Add `FirDesignationWithScript`, because regular designation
does not account for scripts at all - that makes it
cumbersome to add the script's top level and implicit
receiver scopes when collecting contexts for the
non-top-level declarations (class members, for example)
^KT-61689 Fixed
Now that files have a CFG, use it to validate properties are initialized
correctly. Update FirTopLevelPropertiesChecker to collect initialization
info for the property being checked - similar to
FirMemberPropertiesChecker - and validate proper initialization.
#KT-56683 Fixed
#KT-58531 Fixed
In order to properly analyze top-level property initialization, a
control-flow graph must be created for FirFiles. This change adds the
foundation for the file CFG and updates body resolve to create the CFG.
Checking the CFG for proper initialization is separated into a following
change to ease code review.
KT-56683
If a user has multiple kotlin-stdlib libraries in a project, all those stdlib libraries will contain builtins
which will result in resolution ambiguities.
To prevent such kind of ambiguities inside LLFirDependenciesSymbolProvider,
callables are grouped by facade class name.
Only matching callables from the first facade are used.
Facade is a Kotlin/JVM-term so right now it works only for JVM targets.
Builtins are also used in JVM, so the current solution is to have a Facade name also for builtins.
^KTIJ-26760
If a user has kotlin-stdlib in their project,
the IDE should resolve the builtin declarations to the kotlin-stdlib
instead of builtins from the Kotlin plugin.
^KTIJ-26760
`firResolveSession.getTowerContextProvider` should already
contain all the relevant scopes, including default and
importing scopes for the file
Because of this, import and default scopes had presence over the
more local scopes, and the resolve was performed incorrecty - top level
candidates were given higher priority
^KT-61568 Fixed
^KTIJ-26824 Fixed
Although 'VirtualFile's are typically inside the containing package
directory, e.g. 'foo/bar/Baz.class' for 'foo.bar.Baz', there might
be classes with files in unexpected places. Sources of such classes
may include broken stubs, or just classes from misbehaving IDE plugins.
As we are yet to identity such cases, here we treat them as 'other'
candidates.
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.
single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
Denis.Zharkov