but only explicitly. This does not fix a breaking change described in
#KT-52120, because it seems the correct behavior, but it allows
to "workaround" the problem by specifying nullability explicitly.
Also improve handling of nullable bindings in JSR-223.
#KT-49173 fixed
#KT-51213 fixed
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
#KT-48177 fixed
the issue is in fact fixed by the previous commit (report error
on duplicated import) by normalizing import path before processing,
but here we're making error reporting nicer for the case.
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
the dependency on the coroutines library caused various problems like
KT-30778, or stdlib/runtime version conflicts.
The only function used was `runBlocking`, so this change replaces it
with the internal implementation based on the similar internal thing
from the stdlib.
#KT-30778 fixed
#KT-38404 fixed
also:
- Add wrapper class for the location combined with the location id
- Add source code location parameters to external dependency resolvers
- Add tests for locations in annotations
- Add tests for order of annotation resolution for dependencies resolvers
so it is possible now to create custom host configuration with template
and all configurations are handled consistenly.
Also introduce and use new ScriptDefinition class wrapping compilation
and evaluation configurations, that could be consistenly created from a
template.
so the REPL remain operational after exception in one of the snippets:
- separately return script class and script instance on evaluation (
because in case of an exception the class is valid, while the instance
is not).
- store both the class and the instance in the history
- handle this data accordingly
for compilation and evaluation configurations.
Add utilities to apply refinements uniformly.
Also fix one invoke for list values - it was not consistent with
other builders
Yahor Berdnikau