This is needed to avoid dependency on :compiler:fir:fir2ir module in
backend parts of compiler plugins. It will allow to publish those
parts into jars for IDE, where they are needed for working of debugger
and bytecode toolwindow
- `ParentAnnotatedWith` matches declarations, which parent is annotated
- `HasAnnotatedWith` matches declarations, which have at least one
direct child with annotation
Also, `DeclarationPredicate.Any` is removed, because there is no
intention to support lookup for all declarations in module
^KT-52486 Fixed
There was a problem, that after founding of new annotation with meta
annotation we did not come back to previous files, which may contain
declarations with this new annotation
This scheme will be common for all compiler plugins with K1 and K2 support:
- `plugin-common` contains classes shared with K1 and K2 implementations (if any)
- `plugin-k1` contains implementation for K1 compiler
- `plugin-k2` contains implementation for K2 compiler
- `plugin-backend` contains implementation for backend extensions (if any)
- `plugin-cli` is module for registration of plugin in CLI compiler
- `plugin` is a root module with tests and all submodules embedded
This structure is needed to distinguish parts related to different frontends,
which is needed for proper dependencies settings for Kotlin IDE plugins
There are some compiler keys that affect code-generation or set of
linked runtime libraries. If caching is enabled, this would be handled
incorrectly, as cached version can be built with other combination of
this keys.
For now, we just disable cache for all non-default configurations.
This commit adds more correct definition of this non-default.
^KT-52613
- Get rid of SPECIAL mode (just left REGULAR and class-related instead)
- Clear naming
- Restore contexts after lambda/callable reference are processed
The test has been failing before this change because after
callable reference is resolved, its tower data context has been left
erroneously in the SPECIAL-related entry
If we want to analyse some function's call, we need to know about its
contracts, otherwise resolving the following code would be broken.
Computing return type of function is a prerequisite to using it in any
sensible way, so it's the best place to resolve it to CONTRACTS
KT-50733
Dmitriy Novozhilov