Otherwise it's difficult to use a newly added API annotated with
RequireKotlin with the latest, not yet released, version.
For example, suppose there's a new function added in kotlin-stdlib,
since Kotlin 1.3, which requires 1.3 (Kotlin < 1.3 is supposed to report
an error on usages):
@SinceKotlin("1.3")
@RequireKotlin("1.3", COMPILER_VERSION, message = ...)
fun foo() {}
Until Kotlin 1.3 is released, the latest available compiler in Maven has
the version 1.3-SNAPSHOT, which is _less_ than 1.3 according to Maven
rules which are used in getDeprecationByVersionRequirement. Therefore,
errors will be reported on usages of foo, and there's no Kotlin compiler
version which can be used to verify if the function works correctly,
which is inconvenient.
Since SNAPSHOT versions are effectively "pre-release" in a way, it's OK
for them to skip reporting these diagnostics
instead to vie projectDist. With the current project bootstrap scheme a
dependency to the simply built script-runtime project via dist is not
needed anymore, but it breaks proper sources navigation in IDEA.
Introdude deprecation as per KT-21515. Warning is reported on type
usage, that soon will became invisible. Quickfix by adding explicit
import is added.
Idea behind implementation is to mark scopes that are deprecated (see
ClassResolutionScopesSupport).
Then, during walk along hierarchy of scopes, look at deprecation status
of the scope that has provided this classifier.
Note that we also have to check if there are *some* non-deprecated
visibility paths (because we can see classifier by two paths, e.g. if
we've added explicit import) -- then this type reference shouldn't be
treated as deprecated.
Probably, it would be more correct to skip such lambdas when resolving
the returns' references, but it'd be more complicated and still useless
since non-local returns are impossible in such lambdas
(relevant parameter is noinline)
#KT-22900 Fixed
Now ExpectActualDeclarationChecker in IDE context
uses common module descriptors for relevant checks.
Compiler still uses own module instead (see comment in checker)
So #KT-21771 Fixed
This results in more diagnostics usually, but allows library authors to
avoid annotating everything in each experimental class with the marker
(only the class needs to be annotated now)
#KT-22759
- Prohibit non-modifier-like calls on kotlin.suspend
- Add warning on modifier-like calls to anything but kotlin.suspend
#KT-22766 In Progress
#KT-22562 In Progress
Pavel V. Talanov