Support CALL_TO_JS_MODULE_WITHOUT_MODULE_SYSTEM diagnostic
^KT-59377 Fixed
Support CALL_TO_JS_NON_MODULE_WITH_MODULE_SYSTEM diagnostic
^KT-59381 Fixed
Support CALL_FROM_UMD_MUST_BE_JS_MODULE_AND_JS_NON_MODULE diagnostic
^KT-59417 Fixed
This provider is responsible for answering queries related to resolve
extensions. At the moment, this includes retrieving a KtScope with all REx
top-level declarations (moved from KtSymbolFromResolveExtensionProvider), and
retrieving information necessary to supply a GeneratedSourcesFilter for REx
generated code. Future REx-related functions can be added to this interface.
^KT-59329
- Add package and constructor listings
- Add single-scope renderForTests() implementation, including a lambda
to provide additional information about each symbol
- Remove special handling for empty scopes (interfered with single-scope
rendering)
^KT-59329
Tests can now specify the code generated by a resolve extension from
within the test's testdata. Module-level directives control whether
resolve extensions are enabled for that module, as well as package names
and source shadowing regexes. File-level directives allow a `// FILE:`
block within the testdata to be converted into a KtResolveExtensionFile
and removed from the module as a whole. (This requires a new
`ModuleStructureTransformer`, because we need to be able to entirely
remove the files in question.)
Any test can add support for these directives by calling
`KtResolveExtensionTestSupport.configure` from within their
`configureTest` stanza. This allows this functionality to be used in
conjuction with any test base class.
^KT-59329
Inject delegated constructor and other in-place initializer sub-graphs
after the delegated constructor call node. This ensures property
initialization and use is calculated correctly when there are complex
calculations for the arguments to the delegated constructor.
#KT-59708 Fixed
#KT-59832 Fixed
Currently, FirLegacyRawContractDescription is a valid class for
resolved contract in case of error description.
This condition should be dropped after KT-60310
^KT-60310
LLFirTypeTargetResolver in general is responsible for annotation
type resolution, so such checks should be done on its phase.
Also, there is no sense to trying to check a type of annotation mapping
values because they will be initialized only during
LLFirAnnotationArgumentsMappingTargetResolver so, in most cases,
current check during LLFirAnnotationArgumentsLazyResolver is useless
^KT-60295 Fixed
The fresh version of intellij has all record-related declarations,
so an additional fake constructor leads to errors like
KTIJ-25364 (OVERLOAD_RESOLUTION_AMBIGUITY)
^KTIJ-25366 Fixed
^KTIJ-25364 Fixed
^KTIJ-25368 Fixed
^KTIJ-25370 Fixed
originalDeclaration is set for non-local declarations only,
thus requesting symbols for local declarations still goes
with non-physical elements
This lead to ModuleKind.BINARY_MODULE
for `NotUnderContentRootModule`s, because the declaring file is different
KT-60377
Dmitrii Gridin