KtLightNullabilityAnnotation is specifically designed for old light classes
and includes a bunch of hacks that are applicable for them
So, we have to introduce own hack into it
(see org.jetbrains.kotlin.asJava.classes.KtUltraLightParameter#getTypeForNullability)
that is a bit of hard to support when extending hierarchy
It's necessary because after next changes,
they become different for ultra and old light classes.
The former (ultra) is more correct but it doesn't help when
we need to compare our implementation with reference
When making KtLightNullabilityAnnotation after test org.jetbrains.kotlin.idea.caches.resolve.IdeLightClassTestGenerated.NullabilityAnnotations#testJvmOverloads
started failing the wrong assumption was made that for
@JvmOverloads-generated overloads their last parameter is always nullable
(see removed isNullableInJvmOverloads function) and that lead to a bug,
namely KT-28556.
The actual problem of this test started failing was incorrect definition
of kotlinOrigin in KtLightParameter for case of JvmOverloads:
wrong KtParameter was being chosen before
This commit fixes the issue by propagating how actually generated
parameters in codegen relate to source KtParameters'
^KT-28556 Fixed
Previously this files was stored in /src directory and was included in
resources mainly by SourceSet.projectDefault from sourceSets.kt:
val processResources = tasks.getByName(processResourcesTaskName) as ProcessResources
processResources.from("resources") { include("**") }
processResources.from("src") { include("META-INF/**", "**/*.properties") }
Also there are some custom rules like this:
resources.srcDir("../idea-analysis/src").apply { include("**/*.properties") }
resources.srcDirs("idea-repl/src").apply { include("META-INF/**") }
All this rules are synthesized in script
https://github.com/snrostov/kotlin-migrate-resources/blob/master/src/main/kotlin/main.kt
This commit created using that script. See README.md for more details on
script.
Before this commit, function with same name but different signature
wasn't counted as name conflict, now it is - just because that exact
check in this place could be too complex and error-prone
Enhancement for KT-27539
Since at least in gradle-imported projects, the template could be found
in several modules, some of them - incomplete (parent/buildscript module)
the previous logic of filtering for already processed templates and roots
is incorrect, and therefore removed.
Also fixes the exception in our project "cannot load script definition"
Fix 'java.lang.AssertionError: PSI/document/model changes are not allowed during highlighting'
For script when there are some new dependencies we are restarting highlighting (see ScriptDependenciesCache)
In non-gradle project kotlin-stdlib-sources.jar contains sources for common and jvm part, so both (expect and actual) declarations are present in the same library sources scope.
We are moving expect declarations in the bottom of this list to avoid navigation on expect declaration when actual declaration is present in the same scope
^KT-28398 Fixed
Denis Zharkov