I've put `isIncompatibleEnums` to TypeIntersector because I placed
all of its usages after all of the TypeIntersector::isIntersectionEmpty ones
^KT-28225 Fixed
Extract Java-specific code into module 'frontend.java' and use already
existing JavaAnnotationArgument facilities to determine the default
parameter value in an actual Java annotation class.
Annotation arguments are not yet supported because to create an instance
of AnnotationValue, we need a descriptor, which is not available at this
point.
#KT-22704 In Progress
#KT-28077 Open
Before this commit, we compared property visibility with constructor
visibility only, which is incorrect. Now we compare property visibility
also with class visibility
#KT-19613 Fixed
Return type is not needed for checking overloads, but querying it may
involve resolving function bodies, which usually happens after overload
checking (see LazyTopDownAnalyzer.analyzeDeclarations) and at this point
can lead to incorrect BACKING_FIELD_REQUIRED value being computed for
some properties (see KT-27895)
#KT-27895 Fixed
Only invariant array projections and non-null element types will be
supported soon (see KT-26568), so it makes no sense to store the
complete type in KClassValue. What we need is only the ClassId of the
class, and the number of times it's wrapped into kotlin/Array, which is
exactly what ClassLiteralValue represents.
This change helps in decoupling annotation values from
descriptors/types. The only constant value that depends on descriptors
is now AnnotationValue.
#KT-26582 Fixed
Rename 'doCheckContract' into 'parseContractAndReportErrors',
emphasizing that it works with definitely call to 'contract' from
stdlib.
In particular, it means that it should either return non-null
value or report some errors.
Note that this commit doesn't change behavior of this code (modulo cases
when something in 'parseContract' throws exception), but just refactors
the code to be more clear and easy to reason about.
It conveys meaning of the code more celearly (because that's what we
want to do here: set LazyContractProvider no matter how code finished),
and also defends from several corner-cases (like, make sure that we
properly set LazyContractProvider even if doCheckContract has throw an
exception)
Returning `null` from `doCheckContract` functions means that we
have failed to parse contract function and should report an error, but
if the called function isn't true contract, we shouldn't evaluate that code
at all.
#KT-27758 Fixed
Otherwise, top-level function with the name 'equals' and suitable
signature will be (erroneously) treated as true 'equals' invocation,
leading to further exception (see EA-126602)
Equality of those values is crucial for intersecting data-flow info
coming from expressions like: 'this.x != null || other.x != null'.
Using 'ValueDescriptor' for equality is obviously wrong, because then 'this.x'
and 'other.x' will be treated as equal, leading to unsound smartcasts.
This commit adds proper overload of 'equals' to 'ESDataFlowValue' that
will compare them based on underlying 'DataFlowValue' (which already
distinguish those values)
^KT-27260 Fixed
Declare AnalysisFlags in module 'frontend', and JvmAnalysisFlags in
module 'frontend.java', to avoid leaking Java-related logic to common
compiler code
This is effectively a revert of
447c127036, which was an (incorrect) fix
for KT-22379.
The bug was that we've cleared data-flow info for assigned variables
*after* knowledge that loop condition if 'false' was applied (we can
claim that if loop has no jump-outs). Therefore, we broke smartcasts in
the innocent code like that:
var x: Int? = null
while (x == null) {
x = readPotentiallyNullableInt()
}
// x should be non-null here
Commit reverts that "fix" for 1.3.0 and postpones deprecation until 1.4
KT-22379 Open
KT-27084 Fixed
Dmitry Savvinov