The behavior of this part of code is following:
1) We wrap the kotlin light class to the object that wraps the kt files into compiled (!) cls stub (notice, that most of the time it is a single file wrapper)
2) Platform wishes to get the mirror psi of this "compiled" stub work with text of it.
3) Platform request mirror element that asserted to be ok ONLY for multifiles stub.
4) It leads to EA-209577
There is no idea why so, but the exception is high-rated, so this assertion was deleted.
Fixed EA-209577
Preserve type substitution:
- when obtaining function type for SAM type;
- when generating SAM conversions for SAM adapter arguments;
- for "original" method corresponding to a SAM adapter.
Annotation processor classpath for a KAPT run is recorded, and the current
run is compared against the previous one. If those differ, KAPT should
run non-incrementally.
Test: KaptIncrementalWithIsolatingApt.testChangingAnnotationProcessorClasspath
When comparing previous and current classpath snapshots, and it is not
possible to compute the types that changed, make sure to delete the outputs
before invoking KAPT.
Test: KaptIncrementalWithAggregatingApt.testIncompatibleClasspathChanges
```
fun <T : Any> CHECK_NOT_NULL(x: T?): x =
if (x != null) x else throw NullPointerException(...)
```
This allows to compile both Kotlin/JVM and Kotlin/JS effectively.
When bootstrap version is less than from current version dependencies
of `kotlin-scripting-compiler-embeddable` are resolved into projects
which leads to circular dependencies
#KT-33287
Earlier we used a result of a corresponding getter resolution to
obtain a fake overridden field. This approach is incorrect because
the getter resolved may not contain a backing field. This patch
fixes the issue by using the overriddenSymbols property of an
IrField directly.
Issue #KT-33034 fixed
Now, call 'configureDefaultCheckers' and 'configureExtensionsAndCheckers'
from all childs configurators, instead of taking just container from
CommonPlatformAnalyzerServices
This is needed because some IDE services tend to re-create containers
(in particular, PerFileAnalysisCache and ResolveElementCache do that to
re-inject new trace) and use usual injection DSL, which, in particular,
takes 'platformSpecificContainer'.
Returning 'common'-conatiner leads to losing all platform-specific checkers.
On the other hand, calling exactly 'configureDefaultCheckers' +
'configureExtensionsAndCheckers' should be correct, because that's how
single-platform 'platformSpecificContainer' is composed (see
PlatformConfiguratorBase), and in 'createContainerForCompositePlatform'
we don't use 'platformSpecificContainer' anyways
^KT-23305 Fixed
The old compiler will crash if it tries to inline a function that's
passing a lambda parameter into the new parameter null check method
`Intrinsics.checkNotNullParameter` because that usage is not considered as
inlinable by the old compiler (it only knows about
`Intrinsics.checkParameterIsNotNull`). Therefore we require that these
functions can only be read by compilers of version 1.3.50 or greater.
#KT-22275 Fixed
Similarly to previous commit, this method was unused since its
introduction before 1.0, so we're changing its semantics to throw NPE
and starting to use it with API version >= 1.4.
#KT-22275 In Progress
This method was introduced in c204e8fc67 "just in case" and was never
used. Therefore we're free to change its semantics and use it in all new
generated code (with API version >= 1.4), without even worrying that the
newly used API will leak from inline functions in stdlib when used with
an older API version. Since we agreed to change the type of thrown
exceptions to java.lang.NPE in KT-22275, invoke a new method
throwJavaNpe now which throws that exception instead of KNPE.
Note that the additional method that takes an exception message is still
unused and exists just in case we need to use it in the future. The new
method throwJavaNpe is public also "just in case" we need to invoke it
in the future; currently it's not invoked from the bytecode.
#KT-22275 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
Abduqodiri Qurbonzoda