Sealed classes can be derived only by their own inner classes or objects.
Their constructors cannot be called explicitly, so compiler knows all their descendants.
Incompatible modifier checks (final, abstract). Impossible with interface, object, enum.
A pack of tests provided.
- generate fake jump instructions so that we can always analyze stack depths
- fix stack before break and continue by dropping excessive elements (e.g., *a*.foo(*b*, c?:continue))
- Analyzer rewritten in Kotlin, with more flexible control of CFG traversal
#Fixed KT-3340
#Fixed KT-4258
#Fixed KT-7941
A set of tests provided. Some external tests fixed accordingly.
Companion object creation changed accordingly.
Derived classes now can use base class with the private constructor.
Refactoring of AccessorForFunctionDescriptor.
Without this, the unrelated type specified on the LHS of a property reference
literal was considered to be an extension receiver of the candidate, and the
resolution was erroneously successul. This is only reproducible for properties,
because if we're trying to resolve an extension, we consider all properties
from the scope, even non-extensions, because there may be a property of an
extension-functional type (T.() -> R). (We don't do this for functions.)
#KT-7430 Fixed
#KT-7945 Fixed
Refactor: no need to create package view in order to obtain its subpackages
LazyPackageViewDescriptorImpl to replace PackageViewDescriptorImpl
This allows to avoid computations when package views are requested but their contents not necessarily queried
For example: DescriptorResolver.resolvePackageHeader()
The new algorithm: move from right to left, trying to find package, (new code) when found go right resolving descriptors (uses old code)
This allows to avoid unnecessary computations (matters in IDE moslty) for resolving root packages
This changes semantics of imports resolution: when package clashes with any declaration package is preffered
Implemented unqualified 'super' type resolution (in BasicExpressionTypingVisitor).
No overload resolution of any kind is involved.
Corresponding supertype is determined by the expected member name only:
- 'super.foo(...)' - function or property (of possibly callable type) 'foo'
- 'super.x' - property 'x'
Supertype should provide a non-abstract implementation of such member.
As a fall-back solution for diagnostics purposes, consider supertypes with abstract implementation of such member.
Diagnostics:
- AMBIGUOUS_SUPER on 'super', if multiple possible supertypes are available;
- ABSTRACT_SUPER_CALL on selector expression, if the only available implementation is abstract.
#KT-5963 Fixed
Mikhail Glukhikh