Input and output types are crucial for type variable fixation order and
analysis of postponed arguments (callable references, lambdas).
Specifically, if there is non-fixed type variable inside input types of
a callable reference, then we'll postpone resolution for such callable
reference.
Initial example with the expected type `KMutableProperty1<*, F>` caused
problems because input types were computed incorrectly (while there
aren't input types here)
#KT-25431 Fixed
It's needed to estimate the count of steps for type approximation algorithm.
After the estimated count of steps, we consider such type recursive and this
algorithm returns some default value
#KT-28598 Fixed
{ T : Any? & Foo & Bar? }!! -> { T!! & Foo & Bar }
Also, fix bug with loosing non-representative number type.
For example, for type { Byte & SomeType } we lost type `Byte` because
`getDefaultPrimitiveNumberType` returns null for it
Fixes #KT-28334 for NI
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
This test was originally written with fix for KT-22379
Lately, fix was proven to be wrong and reverted (KT-27084), which made
this test fail.
Correct solution here would be to mute test with link to YT issue, but
unfortunately we don't have infrastructure to mute tests locally (yet),
which is a major issue because this tests is a part of very popular for
local smoke-testing test suite (DiagnosticTestsGenerated).
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
If property accessor rendering is disabled in a test, render annotations
on accessors as use-site-targeted, as was done with
`@setparam:`-annotations. Otherwise they were lost
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
Idea is to intersect similar smartcasts on similar properties coming
from *different* instances (something like
'this.x == null && other.x == null' ).
It checks that we distinguish subjects of such smartcasts properly.
Currently behavior is undesired, see KT-27260
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
LazyAnnotations are only used for classes and files, and in the latter
case it will now contain file annotations as normal annotations, without
the target "file:"
Add PropertyDescriptor.backingField/delegateField to store annotations
on the field directly in an otherwise almost empty descriptor instance,
instead of storing them with use-sites in the corresponding property
descriptor. Instead of AnnotationWithTarget, create AnnotationDescriptor
instances in AnnotationSplitter. Change DescriptorRenderer to render
annotations on "related" declarations when needed, with the explicit
use-site target if applicable.
Most changes in diagnostic test data are related to the fact that
annotations which are known to have an incompatible use-site to the
declaration they're applied at (such as `@param:`-annotation on a
function), are now not loaded at all. It's fine because the code is
erroneous, so it doesn't really matter how do we load annotations with
invalid targets (some of this logic is also changed freely in subsequent
commits). Some changes are also explained by the fact that for example
an annotation on the property which is only applicable to FIELD is now
rendered with an explicit use-site target `@field:`, regardless of
whether it did have that use-site target syntactically or not.
Basically, after this change there's no point in calling
Annotations.getUseSiteTargetedAnnotations/getAllAnnotations anymore
because it's easier and more intuitive to just use Annotations of the
corresponding descriptor -- the backing / delegate field (introduced in
this commit) or the extension receiver / setter parameter (related
behavior was fixed in previous commits). Usages of
use-site-target-related methods will be refactored out in subsequent
commits
Before this commit, class super-type could be sealed only in the case
it's the class we are inside or in the same file with.
However, it's quite possible for the expect sealed class
to be implemented by typealias.
So in this commit we allow class super-type to be sealed
if it's typealias expansion we are inside.
Avoid name clashes in cases such as
inline class Login(val login: String)
inline class Password(val password: String)
fun validate(login: Login) { ... }
fun validate(password: Password) { ... }
The design is to use `suspend fun` instead of coercion, just as suspend
lambdas.
However, this syntax is not supported in the parser. But this is not a
problem, since the coercion lead to internal compiler error.
As a workaround everybody uses suspend lambdas.
#KT-24860: Fixed
Alexander Udalov