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
- Add marker for the experimental type inference features
- Add annotation that will control builder-like inference
- Require that annotation on corresponding parameters and extensions
- Allow to use builder inference without suspendability
Changes in tests and refactorings (rename mainly) are going to be
introduced in further commits
They are a kind of a hack applied in light-classes and it'd be nice
to prevent them being used in irrelevant contexts
kotlin-serialization-compiler module should not depend on idea,
thus we can't use annotations directly there.
So, we copy-paste them and add a test on names consistency
Otherwise, whether LazyLightClassMemberMatchingError happens
or other type of errors because serialization plugin expects
full resolution in the correct module
Currently, only @Serializable annotation leads to exceptions,
but just in case we consider both of them as potentially problematic
#KT-26895 Fixed
Alexander Udalov