Listen to changes in files that may affect gradle configuration
Remove configuration request if none of such file was changed since last request
^KT-34442 Fixed
Setting inProgress to false inside run method can lead to multiple notifications because of delay between run method end and progress hide
^KT-34688 Fixed
The goal was to be able to use such symbols before BackendContext is even created – in psi2ir postprocessing step (i.e., IR compiler plugins).
Remove old code from serialization ir plugin.
LazyIR was emitted because plugin was not able to declare symbols, only to reference them.
Moreover, declarations added by frontend plugin were also unbound symbols produced by psi2ir,
and declaration stub generator was stubbing them with LazyIR – therefore access to global symbol table is not enough for plugins. IrProvider won't help here, because some functions produced by plugin have circular dependencies.
By moving compiler plugins step between psi2ir and declaration stub generator, both problems are resolved
– unbound symbols produced by psi2ir and compiler plugins are declared where they would be declared if this was a user code,
and only unbound symbols left are external dependencies, which is a correct input for lazy ir.
Replaced createTemporaryVariable usages with createTmpVariables.
The latter doesn't rely on KotlinType's. Using KotlinType with
JS_IR backend causes runtime excpetions, as some expected descriptor
API is not implemented, because it avoids descriptors as much as
possible.
- See `returnExpressionItems::returnIsProbableInPosition` to get an idea where return is supposed to be more appropriate
- End of the block (except for top level block of unit function or cycle) or as single expression in if or when
- Right side of the elvis operator (which is not already in return)
- Add additional `probable_keyword` weigher to signalize about probable keyword (for now it is only for `return`)
- ^KT-34644 Fixed
Unresolved reference diagnositc was not reported on callable references
returned from if or when expression because of additional block wrapper.
^KT-30953 Fixed
With NO_LOCKS strategy we can easily end up in a situation when
constraint system for a generic call is built incorrectly,
producing flaky errors (or don't produce errors at all)
Now proper storage manager is injected for all cases except:
- IR
- Codegen
- Serialization plugin
- Fake local objects
Most likely, NO_LOCKS strategy for these cases is fine as at that point
the compiler works in one thread
#KT-34786 Fixed
Natalia Selezneva