Type of a block is a kind of irrelevant for lambdas: their type is much
more complicated and defined via FirDataFlowAnalyzer#returnExpressionsOfAnonymousFunction
at at FirCallCompleter.LambdaAnalyzerImpl#analyzeAndGetLambdaReturnArguments
Update includes:
- Changing syntax of `OI/`NI` tags from `<!NI;TAG!>` to `<!TAG{NI}!>`
- Fix some incorrect directives
- Change order of diagnostics in some places
- Remove ignored diagnostics from FIR test data (previously `DIAGNOSTICS` didn't work)
- Update FIR dumps in some places and add `FIR_IDENTICAL` if needed
- Replace all JAVAC_SKIP with SKIP_JAVAC directive
This commit introduces several different things, in particular:
- check type arguments in expressions
- new TypeArgumentList node to deal with diagnostic source
- ConeDiagnostic was moved to fir:cones
- ConeIntermediateDiagnostic to use in inference (?) without reporting
- detailed diagnostics on error type
Before this commit, we had effective visibility as a part of FIR status,
so it was integrated into the full pipeline. In this commit,
we introduced "effective visibility as a service" which is now used
only by exposed visibility checker. This allows us to make the thing
universal for all FIR nodes, including nodes for Java / deserialized.
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"
Denis.Zharkov