If scope doesn't return generated names from `getPossibleCallableNames`,
it's impossible to query them from the scope, since you have to know the
name of callable/classifier to query it
Currently Dokka tasks running for Gradle plugins take quite a lot of
time slowing down local development cycle.
This change disables publishing javadoc on non-CI builds. This could be
lifted by putting 'kotlin.build.gradle.publish.javadocs=true' into
local.properties.
^KT-49227 In Progress
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
The original pattern wasn't enough for matching all files in the
'META-INF/services' directory, especially the 'TestExecutionListener'
service registration that breaks tearDown() in JUnit5 tests in IDE.
Always serialize type table (and version requirement table) after
everything else, to prevent bugs like KT-51446 where inline class
underlying type was added to the type table after it has already been
serialized.
#KT-51446 Fixed
Do not generate linenumber for the start of the finally block, because
that is usually where the only word 'finally' is located. Instead,
generate linenumber for the first expression inside the finally block.
Not generating this linenumber fixes an issue in code coverage tools
which would consider such finally uncovered. Although this might be
technically considered as designed, it makes more sense to NOT detect it
as uncovered because semantics of the finally block shouldn't really
differ whether it's executed normally or because an exception happened.
It's also beneficial for the tool support to behave like javac, which
doesn't generate the linenumber either.
#KT-50973 Fixed
Supported IrDefinitelyNotNullType explicitly for now
(later it will be better to handle it at the call sites)
Co-authored-by: Svyatoslav Scherbina <svyatoslav.scherbina@jetbrains.com>
There are two ways how content roots are registered in compiler configuration
in JVM CLI compiler:
1. Directly from arguments
2. From Module, which build from arguments
And there was a problem that both ways used at the same time in some
circumstances (regular compilation without .xml module file) which
caused duplication of all content roots.
Ideal solution for this problem is removal of Module usages at all,
because it looks like redundant abstraction which just complicate
things, but it's too scary to remove it, because it hove some none
trivial usages inside compiler. So to fix problem with duplicated
roots this commit just removes registration of roots from arguments
if Module is used
Roman Golyshev