See KT-21328
Compiler removes all files from its output directory.
Due to this reason (and some other reasons) it't not a good idea
to put DCE output to `classes` dir.
Therefore we changed output dir to `$buildDir/kotlin-js-min`.
Additionally, we now allow to customize output dir.
In particular, this fixes issues with webpack in multi-project build +
continuous Gradle build.
This behavior was used until 6a1b6d10d8, where the JDK has
unintentionally started to be added to the end of the list, breaking
code which depended on libraries which bundle something from the JDK
#KT-21299 Fixed
For-in-string loop can be generated using specialized 'length' and
'charAt' method calls, and with cached string length.
Note that update of the string variable in loop body doesn't affect
loop execution semantics.
#KT-21322 Fixed Target versions 1.2.20
If the range expression is not a local variable (which can be updated in
the loop body affecting loop behavior, see KT-21354), we can cache the
array length, thus turning a for-in-array loop into a simple optimizable
counter loop.
#KT-21321 In Progress
See the previous commit for information on the kotlin-reflect vs
kotlin-reflect-api distinction.
Add kotlin-reflect as an explicit runtime dependency of most of the test
configurations because even though they all depend on tests-common, the
runtime dependency on kotlin-reflect is not exported from tests-common
to other modules because the projectTests dependency is not transitive.
Existing code for receiver generation accidentally worked in most cases
for object members imported by name. However, it generated strange
bytecode (such as
GETFIELD AnObject.INSTANCE
GETFIELD AnObject.INSTANCE
POP
), and worked incorrectly for augmented assignments.
#KT-21343 Fixed Target versions 1.2.20
This test introduces very special (for current implementation) case,
when we have smartcast indirectly, via some reified type parameter.
It covers recursive call inSmartCastManager.checkAndRecordPossibleCast(),
which wasn't previously covered by any test in testbase.
Currently there are two major phases in NI that report diagnostics: resolution parts and completion. They connected in method `KotlinCallCompleter.runCompletion` and previously diagnostics were collected in several places, from resolution atoms, partly from constraint system and partly from `CallResolutionResult`, some of them were lost.
To mitigate this problem, now diagnostics are not bind to the intermediate candidate, only to the result resolution candidate (overloaded or usual one). And all diagnostics are now collected in method `runCompletion`
Yan Zhulanow