The removed code is probably an outdated code from the age when Kotlin
compiler was using VirtualFiles for operating. Previously the links were
stored and passed further, but now it is only some additional check
(files are unused after the check) with an implicit dependency to
IDEA internals.
The deleted check could probably be responsible for handling references
to JS libraries because of the working compiler daemon.
The code was spotted during an investigation for the
2bf22caeb7 commit (there's a detailed
description in the commit message).
- rename fileToPurenessInitializers onto fileToInitializerPureness
- remove redundant check on top-level property
[JS IR] Rename initialis* to initializ* for consistency
[JS IR] Move propertyLazyInitialization property to context from configuration
[JS IR] Add test on lazy initialization properties order
[JS IR] Add multi module for lazy initialization of properties
[JS IR] Move tests onto js.translator
[JS IR] Rename fileToInitializerPureness according to context name
^KT-43222 fixed
Revert "~~~"
This reverts commit 03fcbfad
Revert "Add an ability to provide own handler for errors inside KotlinJavascriptMetadataUtils.loadMetadata"
This reverts commit 69827fc5
Revert "Add more detailed message for EA-227305 and EA-226744"
This reverts commit b79b3507
Account for JsExport in legacy backend namer. It means we
catch overloaded exported function conflicts for free!
Add error diagnostics:
* NESTED_JS_EXPORT (Fixes KT-36798)
* WRONG_EXPORTED_DECLARATION (Part of the fix for KT-37752)
* NON_EXPORTABLE_TYPE (Fixes KT-37771)
This allows to replace dependency on 'js.frontend' with 'js.config', in
'kotlin-build-common' and 'daemon-common'. Also simplify some other
dependencies.
- Remove klib dependency on metadata and uniqID
- Refactored proto format to make it more effective and compact
-- Use special encoding for some types of data (coordinates, flags, types)
-- Remove symbols table
-- Use packed proto list if it is possible
- Remove extension from metadata
- Remove special ids for function interfaces
- Fix klib IO
- Fix incremental cache
- General code clean up
Sometimes IC raises compilation errors when rebuild succeeds.
This happens because IC uses serialized decriptors
for non-dirty files. Serialized descriptors can be different
from source file descriptors. For example, a source file
may contain an implicit return type or an implicit visibility
for overridden methods, but serialized descriptors always
contain explicit return types & methods' visibilities.
These problems can be solved by expanding a scope of incremental compilation
just after the analysis, but before error reporting & code generation.
In other words, we need to compare descriptors before error reporting and code generation.
If there are new dirty files, current round of IC must be aborted,
next round must be performed with new dirty files.
This commit implements IC scope expansion for JS Klib compiler
#KT-13677
#KT-28233
It allows to fold these blocks and navigate to them in the IDEA.
Also, this commit adds compiler configuration keys to control generating comments with paths for file blocks,
and now generating such comments is enabled only in our tests.
To be able to check descriptor's platform in frontend during plugin processing.
This is needed for serialization plugin because some synthesized descriptors (annotation interface implementation) must be JVM-only (or the Native compilation fails).
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
Before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration
But straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
Otherwise, we have a static initialization loop, leading to null-leaks
Removing default interface method indeed disconnects the loop, as per JVM
Specification, "5.5 Initialization".
See KT-33245 for detailed explanations
^KT-33245 Fixed
As consequence, remove IdePlatformKindTooling.resolverForModule, because
it became more than just field, and it duplicates similar API in
IdePlatformKindResolution anyways
It's needed for situation when we have JS module with expect declaration,
so we refine member scope for that expect declaration and try to
compare to function descriptors (e.g. of `equals` function) from
different class descriptors (expect and actual) and report diagnostic
about name clash. So, since we can earn descriptors from type refinement,
they can be not identical but still equals, so with should use structural
equality to comparing them
Nikolay Krasko