#KT-21696 Fixed
The problem is coming from the fact that `AnnotationTarget.VALUE_PARAMETER` is mapped to receiver parameter and to value parameter, but annotation with use-site target `receiver` can be used only on type reference of receiver parameter
Fixes #KT-23153 for Kotlin 1.3
The problem was in the type check of expression type against expected type. When feature `AssigningArraysToVarargsInNamedFormInAnnotations` (KT-20171) appeared, expected type could be wrong, which led to failed type check
`module` variable is fetched from `moduleInfoByDescriptor`, and this map
is filled in `createModuleDescriptor`, witch is called in
`doGetDescriptorForModule` only for modules from the given set.
Use fake continuation instead of ALOAD 0 while inlining
Do not generate state machine for inner lambdas and inner objects,
which capture crossinline suspend lambda.
#KT-19159: Fixed
Add missing long literal suffix
Add binary integer literals
Introduce IntegerLiteral lexer rule, which is closer to the actual lexer
Issue #KT-22713 Fixed
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
Mikhail Zarechenskiy