For example:
val c = C("...")
val x = c.x // alias to variable for c.x, which depends on c
if (x == null) return
// now c.x has type Any
c = C(null)
// c has been reassigned => info for c.x is no longer valid;
// c itself has never had any statements made about it, but
// we must still call removeAllAboutVariable to clear the
// dependents
If string concatenation contains object value, then this argument
will not have explicit toString call. We must find and check toString
method manually.
#KT-54615
fix(KT-54480): exclude default from the regular reserved keywords to give ability to export intities with default export.
Merge-request: KT-MR-7459
Merged-by: Artem Kobzar <Artem.Kobzar@jetbrains.com>
See KT-49404 for details
In K1, within SubstitutingScope we approximate almost all the types
containing captured types are being approximated to either a lower or
an upper bound.
While mostly, it's being done correctly there are some problems with
approximations for flexible types
So, the parameter's type of A<in Any>::foo is approximated to Inv<in Any!>,
thus allowing to use Inv<*>, while it's obviously unsound.
NB: For the similar example, in B, there are regular TYPE_MISMATCH
because parameter for B<in Any>::foo is approximated to Nothing
Also, it's important to say that
- in K2 everything works because we don't use type approximation there
- approximation algorithm that works incorrectly is only being used in K1
^KT-54332 Fixed
'equals' from any made available for overriding in inline classes
'typed' equals made available for definition in inline classes
'typed' equals definition made compulsory if 'untyped' is overridden
'operator' keyword is allowed in 'typed' equals definition
^KT-24874: Fixed
Handling try/catch and break/continue is too hard here, and failing to
do that properly can create incorrect smartcast. Better be conservative
and assume all code is live.
When a looping control structure has a reassignment with an explicit
receiver, we don't need to erase its smartcast info as it has to be a
non-local property and is thus automatically unstable anyway. However,
we should still do that upon reaching the assignment itself for slightly
more precise error messages (as the property not just "could be"
reassigned, but *has been* reassigned already).
pyos