Duplicated messages in testdata appeared because default renderer
renders diagnostic spans ambiguously. It shows only start position.
In fact, there are 3 failures, 2 of them distinguish only by the
diagnostic end offset. See youtrack for more information.
The issue about inconvenient rendering is KT-64989.
#KT-64608
- This helps to track down disposables which are never disposed, and
reduces confusion when printing disposables in general (the names will
now be meaningful, instead of endless lists of "newDisposable" and
"TestDisposable").
^KT-64099
Some of the incoming paths "absoluteness" may not match the
one of the corresponding library path, and that leaded to incorrect
filtering out some items in the deserialized symbol providers.
Fix the filtering to account for the mismatch.
#KT-57535 fixed
[JS] Remove incremental js jps test
[JS] Remove test of maven js archetype
[JS] Fix another one test
[JS] Fix tests for jps
[JS] Try to fix maven test data
[JS] Fix test data
[JS] Fix test data for ant
[JS] Fix jsExtraHelp test
[JS] Fix test run from not-Gradle build tools
[JS] Set flag without compiler error
[JS] Disable warnings and errors in legacy compiler called from Gradle
[JS] Proofread messages
[JS] Not proofread messages
KT-42326
- just legacy - report warning about deprecation
- both - report warning about deprecation of legacy
- no compiler explicitly chosen - error about explicit setting compiler
warn from cli legacy compiler
nowarn flag - kotlin.js.compiler.nowarn
KT-42326
KT-53074
discrepancy after switching to the new REPL internals was
discovered also on IJ plugin tests, so added a test emulating it.
also some test infra refactoring
also correctly pass externaly provided configuration on compilation
and evaluation.
Fixes REPL evaluation with dependencies passed via compilation classpath.
to support value types erased from runtime classes. See example
in added tests for motivation.
#KT-45065 fixed
also refactor launcher repl test and result type rendering
If the class `A` is in a jar `previous.jar`, the following CLI
invocation will take that class instead of the `A` class
defined in `A.java`:
kotlinc -cp previous.jar A.java B.kt
This is problematic for build tools that put the jar for a
previous build on the classpath when recompiling some of the
files.
^KT-51025 Fixed.
Do not run kotlinc in a separate process in tests which check behavior
of the `kotlin` launcher script.
Locally, the test now runs for 37s instead of 51s.
Otherwise the test would invoke the "java" executable from PATH, which
might not be 1.8, and that would cause some tests to fail because error
messages are slightly different in newer Java versions.
Previously, -Xallow-result-return-type was used to test, whether the
launcher parses -X... flags correctly, however, it has no effect -
returning Result is allowed anyway. So, instead, use -Xno-inline and
check runtime behavior.
Ilya Chernikov