For a class literal Type::class we are resolving Type as a constructor,
getting all diagnostics (about missing arguments, for example) and then
just not committing this trace with errors
#KT-37626 Fixed
This way the check works for callable reference arguments.
Also candidate applicability during resolution does not change compared to the old inference.
^KT-37530 Fixed
Move ParseUtils to 'psi', and ImportPath to 'frontend.common'.
Now 'psi' depends on 'frontend.common', and that allows to remove
dependency of 'fir:tree:tree-generator' on 'psi', allowing the former to
compile in parallel with the old frontend code.
If an inline class is mapped to a reference type (or an array), it's Ok
to treat JVM view on a suspend function as returning a value of
corresponding inline class (although in reality it returns 'Any?'
because of COROUTINE_SUSPENDED).
We can only use IrStrinConcatentation to represent calls to Any?.toString
and toString calls on primitive types. Otherwise, x.toString() and "$x"
are observably different when x is a non-null type with null value
(e.g., an @NotNull value coming from Java).
In particular, this commit includes:
* Attempt to abstract access to FirSourceElement via FirModifier
* Add more visit functions to DeclarationCheckersDiagnosticComponent
* Add messages+factories for 4 modifier-related errors and warnings
* Introduce FirModifierChecker
Rename raw-fir:common to raw-fir:common -> raw-fir:fir-common.
If there's dependency both on :compiler:visualizer:common and
:compiler:fir:raw-fir:common, only one of artifact is left in classpath
First of all, note that currently ControlFlowGraphBuilder instance is fully mutable
and shared between all local classes and top-level classes in the same thread
Before this change, previous node for member of local class
was defined as lastNode
And in the case of implicit types, lastNode might be in a middle of another
local class member that is being resolved right now.
See the test:
- "a.length" expression in `bar` should be resolved because smart cast happens
before the class declaration
- "b.length" expression in `bar` should be unresolved because smart cast happens
in a different function
The latter case has been working incorrectly, the call was errorenously
resolved because "lastNode" were pointed just before "bar()" call in "foo"
The idea is making their mechanics more transparent and clear
Namely, we should move to the next level of designation only for declaration's content
Otherwise there might be some wrong steps when somebody just randomly
calls "transformElement" on the parent declaration.
For example, it happens for local classes when we resolve their supertypes, etc.
Mikhail Zarechenskiy