Annotation arguments with default values are rendered as ... if renderDefaultAnnotationArguments is true.
Tests: java retention does not taken into account by Descriptor comparator.
Java retentinon changed to kotlin retention in some tests + one new test with java retention added.
More accurate tests for intentions in byte code (visibility controlled).
Sometimes it's allowed to parse "annotation" unescaped even if other annotations must be escaped.
A set of annotations and their options tests.
A swarm of existing tests fixed (mostly kotlin.annotation.annotation() added to txt-files).
STUB_VERSION increased. Some quick fixes slightly changed.
Reporting the warning on each "::", as ReflectionNotFoundInspection did, is not
correct anymore, because for example name/get/set on properties works perfectly
without kotlin-reflect.jar in the classpath. So instead we report the warning
on calls to functions from reflection interfaces. This is not perfect either
because it's wrong in projects with custom implementations of reflection
interfaces, but this case is so rare that the users can suppress the warning
there anyway
#KT-7176 Fixed
Get rid of all classes except kotlin.reflect.KFunction, which will be used to
represent all kinds of simple functions.
Lots of changes to test data are related to the fact that KFunction is not an
extension function (as opposed to KMemberFunction and KExtensionFunction who
were) and so a member or an extension function reference now requires all
arguments be passed to it in the parentheses, including receivers. This is
probably temporary until we support calling any function both as a free
function and as an extension. In JS, functions and extension functions are not
interchangeable, so tests on this behavior are removed until this is supported
with type inference error for delegated properties
Add the constraints from completer if they don't lead to errors
except errors from upper bounds to improve diagnostics
It's parameter is FQ-name of class (currently only from builtins) that added as supertype to annotated Java class.
Parameters of annotated class used as non-flexible arguments of added supertype, that helps to propagate more precise types when using in Kotlin.
Some standard JDK collections loaded as they annotated with PurelyImplements.
See tests for clarification.
Before: ArrayList<Int>.add(x: Int!) // possible to add null
After: ArrayList<Int>.add(x: Int) // impossible to add null
#KT-7628 Fixed
#KT-7835 Fixed
In most cases order doesn't matter as in supertype tree built from real code
types with same type constructors should be completely equal.
The only case when order does matter is when we artificially add more specific supertype closer to the root.
For example specific annotation adding non-platform supertype MutableMap<K, V> to ConcurrentHashMap
ConcurrentHashMap<K, V> extends ConcurrentMap<K!, V!> that extends java.util.Map<K!, V!> (mapped to kotlin.MutableMap<K!, V!>)
So we want in that case to use refined (more specific) version when checking subtypes:
ConcurrentHashMap<String, Int> should not be a subtype Map<String!, Int!> (and respectively Map<String?, Int?>)
It should be pure non-platform Map<String, Int> that can be found only with BFS
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.
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
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