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
If a block statement starts with annotations treat them as they
belong to node of the statement rather than to the closest prefix expression
#KT-10210 Fixed
To simplify migration from 1.0 to 1.1, do not allow data classes to
automatically implement abstract equals/hashCode/toString declared in
super-interfaces (KT-11306) if "-language-version 1.0" is specified
Private-in-file declarations conflict with public overload-equivalent declarations
in other files in the same package.
Move functions for grouping possible redeclarations to OverloadResolver
(since they are used only there).
Refactor redeclarations / conflicting overloads reporting.
Unless the compatibility option "-Xsingle-module" is passed, the compiler will
create two modules instead of one now (see TopDownAnalyzerFacadeForJVM): the
main module contains Kotlin and Java sources and binaries from the previous
compilation of the given module chunk, the dependency module contains all other
Kotlin and Java binaries. This fixes some issues where the compiler couldn't
detect that the used symbol was from another module, and did not forbid some
usages which are only possible inside the module (see KT-10001).
The ideal way to deal with modules here would be to exactly recreate the
project structure, for example as it's done in JvmAnalyzerFacade and usages.
This is postponed until later
#KT-10001 Fixed
#KT-11840 In Progress
If a module is configured in such a way that the same function appears multiple
times via different dependencies, it's not helpful to report "none of the
following functions can be called", listing the same function multiple times
Add an assertion to prevent duplicate initialization of CodegenTestFiles
instance in CodegenTestCase, which was happening in ScriptGenTest with multiple
invocation of loadFile()
Denis Zharkov