Denis Zharkov
d74c12323f
Fix ambiguity when KtUltraLightClass contains overrides
...
#KT-27987 Fixed
2018-11-08 15:25:41 +03:00
Denis Zharkov
875e9d2a36
Fix KtUltraLightMethod::getParameterList
...
There's already a correct override in KtLightMethodImpl
Otherwise the tests is failing because clsDelegate.parameterList
has a wrong parent
2018-11-08 15:25:41 +03:00
Pavel V. Talanov
8e470c7c4c
Fix test data
...
Order of members returned by platform changed
Fix test files so test result would not depends on this order
2018-08-16 14:03:01 +02:00
Mikhael Bogdanov
f826a253e3
Generate @JvmDefault for property accessors in LIGHT_CLASS MODE
2018-05-23 13:55:38 +02:00
Mikhael Bogdanov
ec0b9aa343
Skip @JvmDefault in UnimplementedKotlinInterfaceMemberAnnotator
...
#KT-23967 Fixed
2018-04-26 15:36:42 +02:00
Pavel V. Talanov
fae0f611a0
Test java resolve against kotlin file with JvmPackageName annotation
2018-03-06 12:07:07 +01:00
Pavel V. Talanov
8ac7f0b592
Minor: remove error marker from commented out test code
2018-02-12 16:46:16 +01:00
Pavel V. Talanov
9e69c73387
Minor: comment out test for KT-22594 to unmute it on teamcity
...
#KT-22594 Open
2018-02-12 16:35:51 +01:00
Pavel V. Talanov
798c80ed07
Use wrappers around java.util.* to emulate kotlin.collection.* behaviour
...
Backend: If kotlin class extends kotlin.collection.List
write it as it's super interface (light class mode only)
IDE: Provide wrapper classes to java resolve
that try to emulate backend behaviour
For example if kotlin class implements kotlin.collections.Map,
we provide a superinterface that has abstract 'getEntries' method
and 'entrySet' method that is considered default.
In reality all those methods are generated in the class itself.
In IDE supporting this case without hacks is not feasible performance-wise
since kotlin.collection.* may not be an immediate supertype and we need
to compute all supertypes just to calculate own methods of the class
2017-05-16 22:01:03 +03:00
Pavel V. Talanov
4f701285b1
Light class builder: do not generate methods delegating to DefaultImpls in kotlin classes
...
Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
2017-04-09 15:09:01 +03:00
Nikolay Krasko
726471d98e
Avoid loading psi for compiled kotlin file if it's possible to get declaration by name from stubs
2016-12-05 17:22:42 +03:00
Pavel V. Talanov
b275dacad8
Light classes: getOwnInnerClasses() filters out inner classes with null names
...
#KT-13927 Fixed
2016-09-26 19:51:57 +03:00
Pavel V. Talanov
3a3e145de2
KtLightMethod: Wrap return type so it resolves to light method's type parameter as opposed to delegate's
...
Affects java type inference in IDEA
#KT-12090 Fixed
#KT-11095 Fixed
2016-05-27 13:13:01 +03:00
Pavel V. Talanov
62421bbf7b
'const val' are now considered constants by Java in IDEA
...
#KT-12026 Fixed
2016-05-25 15:58:09 +03:00
Yan Zhulanow
a3ff3ffc45
Fix tests: "Placing function type parameters after the function name" error
2015-11-27 15:51:11 +03:00
Pavel V. Talanov
bff7ff0c5d
Improve heuristic to decide whether we will generate DefaultImpls for interface
...
This is not accurate, there are some cases when we will generate DefaultImpls class that are not covered:
- Inherited default implementations
- Annotated members
In these cases IDE will report an error when in fact code compiles
What is critical though is to be able to decide whether to build DefaultImpls light classes solely based on psi without triggering stubs calculation
2015-11-10 14:31:11 +03:00
Pavel V. Talanov
15370244dc
Minor in JavaAgainstKotlinCheckerTest: improve test data for EnumAutoGeneratedMethods case
2015-11-02 18:39:03 +03:00
Pavel V. Talanov
8c4db9bd35
Fix test data so that it can be compiled
2015-11-02 18:38:55 +03:00
Pavel V. Talanov
f6e6ead907
Add java checker test to test loading inner/nested classes
2015-11-02 18:38:53 +03:00
Pavel V. Talanov
be668fc4f5
Introduce JavaAgainstKotlinBinariesTest
2015-11-02 18:38:42 +03:00
Pavel V. Talanov
0b11dc1d7f
KotlinAndJavaCheckerTest: Add test for annotating java code with kotlin annotations
2015-11-02 18:38:25 +03:00
Dmitry Petrov
149e70aa07
Dropping package facades:
...
- light classes: do not generate light class for package facade
- drop package facades as multifile classes compilation mode support
- get rid of some additional package facade fqName usages
- update tests for light classes
2015-10-19 16:03:16 +03:00
Denis Zharkov
bae3320d52
Get rid of deprecated annotations in testData
2015-09-18 10:14:32 +03:00
Mikhail Glukhikh
022e7d1169
Deprecated enum syntax removed: most idea tests
2015-08-10 16:24:16 +03:00
Dmitry Jemerov
1188e57597
rename @overloads annotation to @jvmOverloads
2015-05-27 12:23:08 +02:00
Dmitry Jemerov
625096466e
IDE testdata: s/trait/interface
2015-05-13 16:13:13 +02:00
Nikolay Krasko
90cdb19324
Add origin for generated jvm overloads and tweak equals methods to distinguish them
...
- KT-7586 Strange navigation issue
#KT-7586 Fixed
2015-04-29 15:20:31 +03:00
Nikolay Krasko
ca98b19aba
Wrong package light file with package class
2015-04-01 02:02:07 +03:00
Nikolay Krasko
055be2850f
Fix accept() in light methods elements to avoid treating them as ClsElements
2015-04-01 02:02:01 +03:00
Pavel V. Talanov
9d618ca767
Replace OBJECT$ usages in code and test data
2015-03-25 18:28:01 +03:00
Pavel V. Talanov
06916d98c6
default -> companion: replace all mentions of default and default object
2015-03-17 15:47:39 +03:00
Pavel V. Talanov
59f192ef90
Replace 'class object' with 'default object' in renderers and test data
...
Includes changes to decompiled text
Old syntax is used in builtins and project code for now
2015-03-06 19:36:54 +03:00
Alexander Udalov
fec64b31dc
Fix resolve of Kotlin enum entries from Java
...
#KT-5719 Fixed
2014-09-11 10:37:47 +04:00
Alexander Udalov
70561cc539
Fix resolution of Kotlin enums' values() and valueOf() from Java
...
Use the code from PsiClassImpl / ClsClassImpl, which for some reason is absent
in AbstractLightClass
#KT-5591 Fixed
2014-09-11 10:37:45 +04:00
Nikolay Krasko
97a95d6a6a
Fix "Cannot resolve method" error in Java for methods from trait
2014-08-28 13:47:36 +04:00
Alexander Udalov
de0f751207
Replace object$ -> OBJECT$, instance$ -> INSTANCE$ in the project
2014-07-26 00:21:05 +04:00
Nikolay Krasko
3228630ec5
Update to Idea EAP 134.1342
2014-02-28 15:48:08 +04:00
Nikolay Krasko
9a8a8364dd
KT-4344 "Overridden method parameters are not annotated" warnings from Java
...
#KT-4344 Fixed
2014-02-18 14:49:34 +04:00
Nikolay Krasko
217931622e
Fix for IDEA complains when assigning Kotlin objects where java.lang.Object is expected
...
#KT-4355 Fixed
2013-12-27 15:03:59 +04:00
Nikolay Krasko
74c321ba73
Test for absence static warnings
2013-11-15 19:41:26 +04:00
Mikhael Bogdanov
b3ec87f956
ClassObject instance field refactoring
2013-03-04 16:42:55 +04:00
Andrey Breslav
179456cd0b
Tests for Java name resolution in the IDE
...
#KT-3337 In Progress
LightClasses: class object's property getter unresolved in Java, but compiles OK
2013-02-18 16:05:41 +04:00