#KT-35740 fixed
also add tests and drop logger usage in the cli dependencies manager:
the logger is normally unitialized in the usage scenarios, but related
warnings are annoying.
Previously JS IR versions of stdlib and kotlin-test were build
by default using compiler previously built on a buildserver.
It had some issues:
- This required us to advance bootstrap every time we made any
incompatible IR changes. This happens often since IR ABI is
not quite stable yet.
- We never tested the exact combination of compiler and stdlib we publish
We tested:
- new compiler with new stdlib build by new compiler (in box tests)
- old compiler with new stdlib build by old compiler (in stdlib tests)
We published:
- new compiler with new stdlib build by old compiler
After this change JS IR compiler tests, builds and publishes
single configuration:
new compiler with new stdlib build by new compiler
JS IR stdlib and kotlin-test are now built using JavaExec of CLI instead
of Gradle plugin to avoid troubles of loading a freshly built plugin.
This also allows to have a granular dependencies: we don't rebuild klib
if we changed a lowering in a compiler backend, but we do rebuild it if
we changed IR serialization algorithm.
Call transformer previously ran completion of argument atoms
only for non-error candidates. This led to missing diagnostics,
i.e. from collection literal resolver.
Now arguments of calls resolved to error descriptor are completed,
with exception to not found provideDelegate calls.
provideDelegate's subatoms are not completed after failure, because
it is a part of delegate competion, which does not end with
unresolved provideDelegate.
Completing after provideDelegate failure removes constraint system
from resolved arguments, which breaks resolve for get/setValue.
^KT-33592 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.
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
It was missing during configuration refinement thought new scripting API and during loading script configuration on Gradle project import
Do not pass additional classpath to configuration classpath: this may only affects Gradle with New scripting API (because it isn't used from other places)
In additional classpath kotlin-compiler and kotlin-stdlib was passed and there is no needs for this during loading Script Definitions through new scripting API
^KT-34626 Fixed
When running KAPT incrementally, make sure to pass error/NonExistentClass.java
when there is at least one source file to process. This is to make sure
APs that must resolve all types are able to do so.
Test: updated KaptIncrementalWithAggregating/WithIsolating
This is a refactoring to simplify the API of
ExternalDependenciesGenerator and to constrain future additions of
platform-specific stub generator extensions.
Ilya Chernikov