When "-language-version 1.0" is specified in command line arguments, the
compiler should not be able to see the declarations of type aliases in
libraries, because that corresponds to the behavior of the compiler of version
1.0. Note that type aliases are _completely invisible_ in this mode (i.e.
"unresolved reference" is reported) because they must not interfere with the
classifier resolution
Attach annotations to the closest prefix expression instead of
whole statement if no new line found after annotations
The motivation is for a simple annotated expression like '@ann x + y'
its syntax form must not change after prepending 'val z = ' just before it
This change only matters in cases of if/when/for/while having braceless
blocks
Annotations on them are parsed now as on block-level expressions, i.e.
they're attached to the whole expression
The `@SinceKotlin("X.Y.Z")` annotation now hides a particular declaration from
resolution when the API version specified by the `-api-version` option is
_less_ than X.Y.Z. The comparison is performed as for versions in Maven:
MavenComparableVersion is in fact a copy of
org.apache.maven.artifact.versioning.ComparableVersion.
Also support "!API_VERSION" directive in diagnostic tests
#KT-14298 Fixed
Ensure there's a statically checked dependency on LanguageVersion and
JvmTarget, so that this information is updated automatically once a new
language version or a JVM target is added
Classifiers annotated with `@Deprecated(level = HIDDEN)` now have smaller
priority in imports, similarly to private classes. For example, if two
classifiers named Foo are imported with a star import and one of them is
deprecated-hidden, the name Foo in the source code is resolved to the other
one.
Also a minor change in multi-module diagnostic tests: do not append newlines
after the last module in the test
#KT-13926 Fixed
Since functions usually are hidden from resolution when they are
deprecated-hidden, the problem can only be reproduced for properties with
deprecated-hidden accessors, where DeprecatedCallChecker reported warnings
instead of errors
The main change here is addition of a check that NotNullBasicValue instances
are not being created for non-reference types
Exactly this change should be used instead of f25f0db10e
The latter commit lead to problem described in the KT-14242 issue:
v.getType().getSort() == w.getType().getSort() && (v.getType().getSort() != Type.OBJECT || v.equals(w))
Problem is that the condition above returns true without calling `v.equals(w)`,
because the sort of type is ARRAY, not OBJECT, so testArray was being treated
as NotNullable erroneously
So the second part of this change is effectively revering mentioned commit
#KT-14242 Fixed
Vsevolod