Applying plugins leads to failures when matching members in LazyLightClassDataHolder
because plugins rely on analysis results
This decision has its drawbacks (java won't see results of plugin execution)
but more work on light classes is needed if we want to support this usecase
We can argue that plugins should only generate synthetic members
but there is no such restriction atm
Otherwise any cached reference to light class can lead to severe memory leaks in IDE
since LightClassBuiderResult holds GenerationState which holds ModuleDescriptor
that was moved to the script-runtime, that it a row caused the incompatibility
with old GSK implementations. Now the legacy template resolving related code
is restored, marked obsolete and wrapped for compatibility with the new code.
Added resolving the compiler jar using the class loader urls as the
first step with the fallback to the original resolution method. Also
helps if the compiler is not present in the classpath dependencies.
Issues: #KT-16580 Fixed
Changed to getting plugin version from the applied plugin instead of
the plugin JAR name.
Removed unnecessary working with version of AbstractKotlinPlugin.
(cherry picked from commit ea3adb0)
Added reverting processor path back.
Appending processor path instead of setting it.
Issues: #KT-17255 Fixed
(cherry picked from commit 843844b)
Added a test checking that -processorpath is set for all Gradle versions
(cherry picked from commit bda59e5)
Sometimes an expression `versionFile.readText()`
returns an empty string, so that `toInt()` fails
with `NumberFormatException`.
It can happen in with both JPS and Gradle.
I could not reproduce the problem,
and it seems to be impossible (under normal circumstances),
because we always write a non-empty string,
and the file is checked to exist before reading.
Maybe it could be caused by an FS error.
The only "solution" to the problem I could think
is to swallow the exception, and assume
that cache version is not valid (so it would cause a rebuild of a module).
#KT-17125 fixed
Fixing the problem introduced in the commit 9819de1abd:
the daemon client messages should be reported
when the debug log level is enabled
or when the connection not successful
#KT-17199 fixed
#KT-11916 fixed
To use the IC either:
1. set the `kotlin.compiler.incremental` property to `true` in a pom.xml:
```
<properties>
<kotlin.compiler.incremental>true</kotlin.compiler.incremental>
</properties>
```
2. pass the `kotlin.compiler.incremental` property in a command line:
```
mvn install -Dkotlin.compiler.incremental=true
```
When IC is on Kotlin plugin is expected to print the warning in the log:
```
Using experimental Kotlin incremental compilation
```
After each call an incremental compiler will also log how many files it has compiled:
```
Compiled %SOME_NUMBER% Kotlin files using incremental compiler
```
Note that the first build will be non-incremental.
For more diagnostic information (such as an exact list of compiled files) use the `kotlin.compiler.incremental.log.level` system property:
```
mvn install -Dkotlin.compiler.incremental=true -Dkotlin.compiler.incremental.log.level=info
```
To force the rebuild just run the 'clean' goal:
```
mvn clean install
```
Codegen generates clean instructions for ref values (captured vars)
on block exit so we should delete them on dereferencing captured values.
#KT-17200 FIXED
(cherry picked from commit b51cb9a)
Dex doesn't recognize ANEWARRAY [Ljava/lang/Object; types as Object [][], but Object [].
It's not clear is it bug in dex or not
#KT-17200 InProgress
(cherry picked from commit f3e2abf)
To provide consistency between light classes and their delegates
IdeLightClass#testExtendingInterfaceWithDefaultImpls still failing since
we do not generate implementations delegating to DefaultImpls of superinterfaces
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
The <Type>Array.iterator used to lack next<Type>() method (KT-16626).
The -Xtypedarray compiler key enables translation of primitive arrays
to TypedArrays, and primitive array`is`-checks (KT-15358, KT-14007,
KT-14614, KT-16056).
(cherry picked from commit 9b34e21)
It is not reported for 1.0 language version because
renaming to _ is not possible. It has weak warning severity
So #KT-8813 Fixed
So #KT-16875 Fixed
(cherry picked from commit 7a53b2f)
xercesImpl was unnecessarily added to the compiler uberjar during migration
to the idea platform 171. This caused NCDFE about classes from org.w3c
package.
And to simplify application of this commit and to ensure that only required
jars are packed into the uberjar, the build.xml was altered to use
explicit list of the jars from the ideaSdk/core directory, rather than
a mask.
Fixes #KT-17143 and #KT-17157
Avoid resolving references when we know from context that a reference
at given location can't resolve to a PsiMethod.
(cherry picked from commit f255f2a)
Forbid underscore-only (_, __, ___, ...) names as callees and as types.
If CHECK_TYPE directive is on, filter out UNDERSCORE_USAGE_WITHOUT_BACKTICKS messages.
Added @Input to the property returning classes dirs: it will make
Gradle fall back to non-incremental input when the property value
changes.
Issues: #KT-16820 Fixed
(cherry picked from commit 9ba84df)
Added version check to switch between old and new approaches because
Gradle versions before 2.14 have a bug in Java IC.
Added Kotlin classes to Java task input.
Added annotationsFile into task input to include it into up-to-date check.
Related issues: #KT-16585 Fixed
(cherry picked from commit cc0ac36)
Types of the corresponding parameters (or type parameter bounds, types
in supertypes, etc) are now compatible not only if they're equal, but
also if values of those types are mutually assignable (if "a" is subtype
of "b" and "b" is subtype of "a")
#KT-17005 Fixed
(cherry picked from commit b971ac9312)
This fixes KT-17001 because now 'header' modifier is loaded correctly
for deserialized members and the standard disambiguation in
OverloadingConflictResolver.compareCallsByUsedArguments takes place,
where header members are discriminated against the corresponding impl
members
#KT-17001 Fixed
(cherry picked from commit db1f039586)
The inheritance is still needed because of the code in intellij-core,
specifically in JavaCoreProjectEnvironment.addSourcesToClasspath and
CoreJavaDirectoryService.getPackage, which assumes that the
JavaFileManager instance in the project is a CoreJavaFileManager
(cherry picked from commit 1c7ac2da5a)
findClass(String, GlobalSearchScope) is invoked for example when we're
resolving supertypes of classes in Java libraries. Previously, it never
found nested classes and falled back to CoreJavaFileManager's
implementation, which lacks a fix for the original issue (KT-12664,
which was fixed in JvmDependenciesIndex in 5a533a52 and 164c72e8)
#KT-16931 Fixed
(cherry picked from commit c67eb84369)
- Move collectKnownClassNamesInPackage to the only place where it's used
- Fix warnings/inspections and simplify implementation a bit
(cherry picked from commit f1a1ebae01)
Split KotlinPsiElementFinderImpl into two classes: one is used in the
compiler (boolean field isCliFileManager previously handled that), the
other is used in IDE and possibly other non-CLI scenarios.
Also avoid a possible class cast exception in
KotlinJavaPsiFacade.knownClassNamesInPackage
(cherry picked from commit 801a93edbc)
Fix CCE on callable references to Java methods.
Fix qualification of callable references without receivers.
Fix processing of calls/callable references to object extensions
and extension members.
Do not explicate short companion references
#KT-16809 Fixed
(cherry picked from commit 1d01624)
This is temporary fix due to KT-13934 which prevents resolution
of references like X::foo where foo is a member or extension
of X companion object
(cherry picked from commit aad11ff)
'tools_jar_profile' Maven profile is activated only if 'kotlin-annotation-processing-maven-build.txt' exists.
It already works this say for the 'kotlin-annotation-processing' artifact.
Relates to KT-15562 "Service is dying".
This commit includes multiple changes:
1. JPS & Gradle daemon clients are refactored to use `connectAndLease` from `KotlinCompilerClient`.
`connectAndLease` was introduced in previous commits
2. `withKotlin` was removed because `connectAndLease` already covers retrying on connection error
3. Gradle flag files creation is changed:
* client-alive flag file lives as long as Gradle instance lives,
* session-alive flag file lives until the end of a build.
Before this change a daemon client debug messages were printed
only when the client could not connect and the 'kotlin.daemon.verbose'
system property was set up.
Now messages are printed if the debug logging is enabled and
the 'kotlin.daemon.verbose' is set up.
#KT-16917 fixed
The daemon code contained the following code:
```
ManagementFactory.getRuntimeMXBean().name
```
As it turns out `RuntimeImpl#getName` calls `VMManagementImpl#getVmId`,
which in turn calls `InetAddress.getLocalHost().getHostName()`.
`InetAddress.getLocalHost()` tries to resolve by making a DNS-request.
In case of a DNS-problem or a network misconfiguration,
resolving localhost can be very slow,
so a daemon client can disconnect
by the timeout (10 seconds) and fallback to the non-daemon compilation.
This change removes the call `getRuntimeMXBean().name`
(it is only used for logs).
The RMI documentation (http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/javarmiproperties.html)
says it is useful to set up a `java.rmi.server.hostname`
system property on a client and a server.
When the property is set up on a client, I saw that "RenewClean" threads
stopped listening to my external IP, so all client and server threads
are now only listening the loopback interface.
I also changed the way the property is set up on the server side:
before the change it was passed in jvmargs at a process launcher.
I moved this code directly to the main method of the daemon,
because it is easy to forget to set up the property,
when running the main for debug purposes.
It takes time to find compile errors or exceptions,
when a Gradle test build fails, because a debug log
is very verbose.
This change prints all error messages from Gradle
when a test build fails unexpectedly.
Probably due to switching to the JDK8, the daemon tests became more flaky.
Making it less reliable on the log file closing. And try to close log files
on the daemon side.
Also improving diagnostics on many tests.
Also weaken parallel daemon start test a bit since it seems it is failing
on the RMI timeouts now.
Replace `takeIf { !expr }` with `takeUnless { expr }`.
Cleanup redundant parethesis as in `listOf((expr))`.
Replace `listOf(expr)` with `expr.let(::listOf)` where the former caused significant indentation change.
Ignore classes (and references to such classes in declaration signatures) if one of the containing classes has the same simple name. This is forbidden in Java, thus should not be present in kapt source stubs.
Use the bundled compiler plugins for Maven projects (as we do for Gradle projects already) because the plugin provided as a dependency in the POM file may have an incompatible version.
After update of the project to JDK 8, the default JDK at java.home is
now JDK 8. However, this test relied on the fact that the default is JDK
6. Pass the path to the JDK 6 explicitly
Previously, type substitution, which is critical for matching generic
header/impl members with each other, was only performed when
checkImplementationHasHeaderDeclaration was called for impl class
(areCompatibleClassifiers creates the correct substitutor). This was
done in areCompatibleClassifiers: a substitutor which maps type
parameters of the header class to type parameters of the impl class was
created.
Now we create the same substitutor when
checkImplementationHasHeaderDeclaration is called for an impl member of
an impl class as well, manually.
#KT-15230 Fixed
Similarly to getFirstClassifierDiscriminateHeaders, we select the first
non-header class if possible, otherwise we select just the first class.
This makes sure that a reference will never be resolved to a header
class if the corresponding impl class is present.
Note that overall the issue may not be fixed yet, because there are
other scopes where header classes are not yet discriminated
(LazyImportScope, DeserializedMemberScope). However, at this point I
cannot reproduce this problem with these other scopes
#KT-15521 Fixed
Compile the platform-specific code two times: once with the common file
first and the platform file second, and once with the platform file
first and the common file second in the compilation arguments. This is
needed because some issues in the compiler are only reproducible in one
of these two scenarios
Currently this is achieved with several hacks:
- Postpone computation of argument type info when there is no candidate resolver. We have to do this, because we don't have expected type and therefore we could write wrong information to trace
- Presume that for annotation calls there is only one candidate resolver and then resolve arguments with expected type (see `getArgumentTypeInfo`), otherwise because of quadratic complexity of the algorithm resolve would be slow
Avoid temporary file rename if the current name doesn't conflict
with other files in the target directory.
Improve protection against exceptions during the refactoring
which may prevent final rename
The light analysis test data is not needed anymore cause the light analysis result is now automatically checked against the one from the full analysis.
allows to compile only parts of the source files, denoted by top-level
"sections" (function with lambda param calls), but preserving original
file line/column numbers for easier diagnostics. Allow e.g. to compile
gradle "buildscript" section without preprocessing original file in
advance. See tests for examples.
Replaced adding Kotlin sources with dependency on copy*KotlinClasses,
which might not be called since Android Gradle plugin sometimes
bypasses the tasks in finalizedBy .
Added a test for androidTest build apart from general build.
Issues: #KT-16897 Fixed
Deferred resolution of JAR-to-AAR mapping, since the Android Gradle
plugin now resolves dependencies at execution phase.
Dropped the code related to the Jack toolchain compatibility.
Throwing a build error when Jack is enabled.
Changed warning about Jack into a build error.
BasicCompletionWeigherTestGenerated$ExpectedInfo.testPreferMatchingThis
Looks like IDEA now rearranges elements with same weight by length and
then alphabetically
Previously we could differentiate between callables with the same name
when relevant type declaration were in the same file only
Problem manifested most severely when several copies of sources were attached
to the same library
Rename to getNonConfiguredModulesWithKotlinFiles() to match what it
actually does, remove duplicate configurator status check, extract code
for collecting all configurators
Report CAN_BE_CONFIGURED from Gradle configurator only if we didn't
find any file containing valid configuration (normally the top-level
project file in an Android project doesn't have any Kotlin
configuration, so we report CAN_BE_CONFIGURED even though the module
file contains valid configuration)
Don't show notification after every sync; trigger it from
rootsChanged handler because the root model is not yet updated at
syncDone point
#KT-16590 Fixed
Filter out duplicate reference targets.
Fix test data as directory references are available
inside of string literals.
Fix test data as Spring @Autowired inspection
no more reports parameterless methods.
Fix gutter checking as configuration bean references now resolve
to @ComponentScan annotation
CompletionContributor should not store offsets inside
replacement zone(part of file which are replaced with
dummy identifier) in offsetMap
#KT-16848 fixed
Otherwise, when we check the highlighting on one of the files, the text
of the other still contains the <lineMarker> annotation and can't be
indexed as valid Kotlin code.
- Use FULL_JDK instead of mock JDK in some tests because mock JDK is
created from JDK 6 and full JDK is now JDK 8, so there are differences
in the behavior in the compiler and at runtime
- Remove some '*.runtime.txt' files which were workarounds to JDK 6
reflection issues regarding generic inner classes; code in these tests
is now loaded exactly the same in the compiler and at runtime
- Change supertype in SupertypesAndBounds.kt: the class in the supertype
is not relevant to that test, it checks that annotations can be loaded
on types
- Use another API to get file name out of a javac diagnostic
(.getSource().getName()'s behavior changed in JDK 8)
- Delete .txt files for those tests which check that javac reported a
compilation error; the order and content of declarations in those
files is undefined
In tests the code is executed in EDT and runInReadActionWithWriteActionPriority fails
See: MergingUpdateQueue.setPassThrough() and ExternalToolPassFactory() constructor
Lexer monitors "long string template" state end and will produce
LONG_TEMPLATE_ENTRY_END token when it is reached. If parser continues
without waiting for it, it will eventually get handling token that
will produce irrelevant error. Such behaviour also breaks lazy
elements (LAMBDA_EXPRESSION in this case) contract: range of parsed text
in eager mode should be same to one parsed in lazy mode.
#KT-14865 Fixed
Allow the compiler to read such libraries without any errors, at the
risk of crashing with an exception.
Also fix a minor bug in the diagnostic message in LibrarySourcesConfig
and in the corresponding test in KotlinJpsBuildTest
Do not show file chooser twice.
Disable/enable control on component initialization and change of
"Use project settings" option
#KT-16952 Fixed
#KT-16953 Fixed
Some IDE features relates onto that same descriptors will remain same
between resolve calls
Fix it to be true for TypeAliasConstructorDescriptor's
#KT-16265 fixed
Sharing these settings for reading/writing
between different module during JPS build
may lead to compiler settings
(plugionOptions, in particular) of several
modules to be mixed
#KT-16888 Fixed
Favor language/api version specified in <versionInfo> element
in case it differs from the one in
<option name="_commonCompilerArguments">
#KT-16861 Fixed
Revert "Problem: manually shutdown AppScheduledExecutorService to allow compiler stop properly"
The commit was added during update to 162.1024.1 to fix hangs in ant
tasks on teamcity because of some thread created in
AppScheduledExecutorService service.
Remove the commit because can't reproduce those hangs under 162.2946
(Probably 12a079ef41 fixed the hangs).
This should also be addressed in fix for https://youtrack.jetbrains.com/issue/IDEA-169562
This reverts commit 99a75021e1.
Step 0: Light class object is created, no delegates are computed
Step 1: constructs dummy delegate which can not be relied upon to know signature of any member
It can be used to construct light field and light method objects
(which can correctly respond to some queries) before constructing real delegate
Step 2:
Construct real delegate if dummy delegate is not enough to respond to a query
This speeds up multiple scenarios where getMethods() and getFields() are called on numerous classes
Dummy delegate's faster consruction is achieved by using specially setup dumb analysis instead of ide analysis
Introduce LazyLightClassDataHolder: which manages creation of Step 1 and Step 2 delegates
Introduce MemberIndex: keeping track of member creation order, helps matching light class delegates created in different contexts
KtLightMethod and Field: make use of dummy delegate
KtLightMethod no longer extends LightMethod since it requires eager delegate construction
KtLightMethod now implements PsiAnnotationMethod for convenience (ClsMethodImpl implements PsiAnnotationMethod)
Introduce LightClassDataHolder: which now is reponsible for constructing clsDelegate
Move out light big chunk of delegate building logic out of LightClassDataProvider into LightClassBuilder
LightClassData only holds information about single class
Consider this code:
object Delegate {
operator fun getValue(t: Any?, p: KProperty<*>): String {
return ""
}
}
class A {
val String.ext by Delegate
}
then the type of <p> is KProperty2 (it has 2 receivers).
Test fix + review fixes
Pass it in the CompilerConfiguration instead of LanguageVersionSettings.
This is better because LanguageVersionSettings is accessible everywhere
in front-end and back-end, and this flag should not be used there
Previously there were three LanguageFeature instances -- Coroutines,
DoNotWarnOnCoroutines and ErrorOnCoroutines -- which were handled very
awkwardly in the compiler and in the IDE to basically support a language
feature with a more complex state: not just enabled/disabled, but also
enabled with warning and enabled with error. Introduce a new enum
LanguageFeature.State for this and allow LanguageVersionSettings to get
the state of any language feature with 'getFeatureSupport'.
One noticeable drawback of this approach is that looking at the API, one
may assume that any language feature can be in one of the four states
(enabled, warning, error, disabled). This is not true however; there's
only one language feature at the moment (coroutines) for which these
intermediate states (warning, error) are handled in any way. This may be
refactored further by abstracting the logic that checks the language
feature availability so that it would work exactly the same for any
feature.
Another issue is that the difference among ENABLED_WITH_ERROR and
DISABLED is not clear. They are left as separate states because at the
moment, different diagnostics are reported in these two cases and
quick-fixes in IDE rely on that
Inject LanguageVersionSettings instead; all information relevant to the
analysis should be now passed via an instance of LanguageVersionSettings
(which should be renamed to a more general name in the future).
This is partially a revert of d499998 and related commits
This makes it possible to avoid the CompilerConfiguration instance in
injectors, because CompilerDeserializationConfiguration was the only
left component that required it.
LanguageVersionSettings is not a good name for this entity anymore, it
should be renamed in the future
This makes it possible to drop CompilerConfiguration from
CallCheckerContext, which in turn helps to avoid passing the entire
CompilerConfiguration instance through front-end
Previously JvmTarget was declared in module 'util' which is accessible
for example from 'frontend', which is not very good.
Also add a superinterface named TargetPlatformVersion which is going to
be used in platform-independent injectors in 'frontend' in the following
commits. Use it in one place (LanguageVersionSettingsProviderImpl.kt)
instead of DescriptionAware because TargetPlatformVersion sounds like a
better abstraction than DescriptionAware here
Before this change the check was quite complicated
because of cases like:
for (i in 1..9)
foo(i)<caret>
It's not located in a block, but in the same time it's a stament.
So we had a tricky heuristics that if is parent is not a block, then
we should check if element isn't used as expression.
Of course this heuristics is wrong, e.g. for import/package nodes.
The solution is to reuse similar logic from BasicExpressionTypingVisitor.
it has been checked once that statement container is one of:
- KtBlockExpression
- KtContainerNodeForControlStructureBody
- KtWhenEntry
So there's no need to check anything else
#KT-14986 Fixed
#KT-14483 Fixed
Allow to specify predicate by KtExpression instead of type predicate
It will be used for `for` template which need a context to determine
whether the expression is iterable
Added "Unused return value of a function with lambda expression body" inspection with quickfix "Remove '=' token from function declaration"
#KT-10393 Fixed
Inline lambda could capture reified parameter of containing inline function ('a' function)
when it is inlined in another one.
If it's inlined in any anonymous object we should track it and
add reification marker to such anonymous object instance creation
to rewrite it on inlining bytecode of 'a' function.
#KT-15997 Fixed
This would allow building the project with Kotlin JPS plugin on TeamCity where older library takes precendence due to appearing earlier in JPS classpath
Allow kotlin.jvm.internal.Intrinsics#areEqual for boxed values.
Rewrite to primitive equality.
NB we can't do that for Float and Double, because java.lang.Float#equals
and java.lang.Double#equals behave differently from primitive equality comparisons.
CHECKCAST is redundant if the corresponding static type exactly matches the target type.
CHECKCAST instructions to-be-reified should not be eliminated.
KT-14811 Unnecessary checkcast generated in parameterized functions
KT-14963 unnecessary checkcast java/lang/Object
KT-16194 Code with unnecessary safe call contains redundant boxing/unboxing for primitive values
KT-12839 Two null checks are generated when manually null checking platform type
Recognize some additional cases of trivial null checks and trivial instance-of checks.
A variable is "checked for null", if it is:
- a function parameter checked with 'INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull'
- checked for nullability with 'IFNULL/IFNONNULL'
- checked for nullability with 'INSTANCEOF'
(if objectref is instance-of T, then objectref is non-null)
Before analyzing nullability, introduce synthetic assumptions for execution branches
where a variable is guaranteed to be null or not null. For example, the following bytecode:
ALOAD 1 // Ljava/lang/String;
IFNULL L
<non-null branch>
L:
<null branch>
is transformed to
ALOAD 1
IFNULL L1
NEW java/lang/String
ASTORE 1 // tells analyzer that variable 1 is non-null
<non-null branch>
L:
<null branch>
L1:
ACONST_NULL
ASTORE 1 // tells analyzer that variable 1 is null
GOTO L
After the analysis is performed on a preprocessed method,
remember the results for "interesting" instructions
and revert the preprocessing transformations.
After that, perform bytecode transformations as usual.
Do not transform INSTANCEOF to-be-reified, because reification at call site
can introduce null checks. E.g.,
inline fun <reified T> isNullable() = null is T
...
assert(isNullable<String?>())
This patch mutes the following test categories:
* Tests with java dependencies (System class,
java stdlib, jvm-oriented annotations etc).
* Coroutines tests.
* Reflection tests.
* Tests with an inheritance from the standard
collections.
It's expected that for call expressing some nearest parent will have
lexical scope written in binding context. Under this circumstances it's
refactoring.
getStrictParentOfType() looks for nearest parent of given type
In complex expressions like:
SamConversion.doAction({
inlineCall {
{
// here <--
}()
}
})
doAction was found twice, while inlineCall was skipped.
See code:
// call(param, { <it> })
lambdaExpression?.typedParent<KtValueArgument>()?.typedParent<KtValueArgumentList>()?.typedParent<KtCallExpression>() ?:
// call { <it> }
lambdaExpression?.typedParent<KtLambdaArgument>()?.typedParent<KtCallExpression>()
#KT-11234 Fixed
For ordinary functions mapSignature doesn't use original descriptor
and maps the given descriptor itself, but for constructor it obtained
the original value parameters.
Necessary `getOriginal` calls were added to the call-sites
It should not affect the semantics, because mapSignatureWithCustomParameters
can only be called with FunctionImportedFromObject from mapSignature.
At the same time it's very nice to have all of these kinds
of custom unwrapping in the same place
There's no need in unwrapping for TypeAliasConstructorDescriptor
because mapSignatureSkipGeneric/mapDefaultMethod already do it
in some moment, and ConstructorDescriptor has getConstructedClass method
for mapping its owner
The problem was that when resolving super-calls we used known substitutor
when creating a type alias constructor, thus its original return itself,
while it's expected that it should return the descriptor before substitution
The main idea of the fix that `createIfAvailable` should always return
unsubstituted constructor.
Note that known substitutor for type alias constructor should be based
on abbreviation.
The test change seems to be correct as PROJECTION_IN_IMMEDIATE_ARGUMENT_TO_SUPERTYPE
is already reported.
Beside this, resolution behavior isn't expected to be changed dramatically
The problem is very subtle (see the test): when generating a signature
for an object literal we also were mapping its super-class
(a type alias here).
Although we did unwrap its underlying constructor to map it properly
we did too late (after obtaining value parameters from the type alias constructor descriptor).
Another problem is that TypeAliasConstructorDescriptor.getOriginal
in the case does return itself, while it's expected to return
unsubstituted version
Note: everything works for common calls for such constructors
because they mapped through mapCallableMethod which contains
another custom unwrapping of type alias constructors
#KT-16555 Fixed
See how we translate raw types to Kotlin model:
RawType(A) = A<ErasedUpperBound(T1), ...>
ErasedUpperBound(T : G<t>) = G<*> // UpperBound(T) is a type G<t> with arguments
ErasedUpperBound(T : A) = A // UpperBound(T) is a type A without arguments
ErasedUpperBound(T : F) = UpperBound(F) // UB(T) is another type parameter F
Stack overflow happens with the following classes:
class A<X extends B> // NB: raw type B in upper bound
class B<Y extends A> // NB: raw type A in upper bound
when calculating raw type for A, we start calculate ErasedUpperBound(Y),
thus starting calculating raw type for B => ErasedUpperBound(X) => RawType(A),
so we have SOE here.
The problem is that we calculating the arguments for these raw types eagerly,
while from the definition of ErasedUpperBound(Y) we only need a type constructor
of raw type B (and the number of parameters), we don't use its arguments.
The solution is to make arguments calculating for raw types lazy
#KT-16528 Fixed
Internal packages which are hard-excluded from completion and
imports now should be visible there if file package are parent of
excluded one
e.g kotlin.jvm.internal.* now visible from kotlin and kotlin.jvm
#KT-16214 fixed
Added .property files to make the plugins available by fqnames in
order to publish them to Gradle Plugin Portal.
#KT-5756
(cherry picked from commit 991de64)
Instead of verifying that the container of an 'invoke' is a
FunctionClassDescriptor instance, make sure that it's a function class
checking its FQ name instead (classId + isBuiltinFunctionClass calls).
This makes sure that we will create synthesized invokes in a setting
where function classes are not FunctionClassDescriptor instances
synthesized by the compiler, but ordinary classes from sources or
binaries as well, as is going to be the case in kotlin-native
Members declared in interface or overriding members declared in super-interfaces
can be implemented by delegation even if they override members declared in super-class
(NB for interface this can be only 'kotlin.Any').
(it can be different from 'getContainingDeclaration()' in case of type alias constructor).
KT-15109 Subclass from a type alias with named parameter in constructor will produce compiler exception
KT-15192 Compiler crashes on certain companion objects: "Error generating constructors of class Companion with kind IMPLEMENTATION"
1. Analyze method node with fake jumps for loops to make sure that
all instructions reachable only through break/continue jumps are processed.
2. Fix stack for break/continue jumps.
3. Drop fake jumps for loops, analyze method node again.
4. Fix stack for try/catch and beforeInline.
Generate 'do-while' loop body as IrComposite, because variables declared
in loop body should be visible in loop condition.
Wrap 'do-while' loop in IrBlock so that variables declared in loop body
are not visible outside of the loop.
Generate 'while' and 'do-while' loops as expressions of type Unit.
Instead of requiring to pass it in SerializerExtensionBase's
constructor, pass it always in serializePackage. This is more
straightforward and helps in a situation where one SerializerExtension
instance is used for the whole module, not one per-package
Added a workaround reflection call to TaskManager to create a
javac task since it is missing for androidTest variants with jack.
Added source configuration with the tested variant to make
the tested sources visible to the compiler.
#KT-16434 Fixed
(cherry picked from commit 84efd05)
The only remaining usage was in KotlinRuntimeLibraryUtil.kt where we only
needed to check whether there's at least one file in a given package indexed by
KotlinJavaScriptMetaFileIndex. Move that logic to a public extension, drop
everything else
Move 'generateExpressionForReferencedDescriptor' to CallGenerator,
use it in 'generateCall',
add PSI-free versions of some utility methods so that call elements can
be generated when we're already deep in ResolvedCall generation
and have forgotten about PSI.
There are two different tests: the one that checks that all versions are
consistent (but not equal, because some versions are major.minor.patch,
but some only major.minor), and the one that checks that versions of all
subprojects of the Maven projects are exactly equal (1.1-SNAPSHOT
currently)
#KT-16455 Fixed
Before this change such wrapping happened only during coercion,
i.e. when a call-site expected a KClass instance.
But when call-site expects Any, for example, no wrapping happened,
and raw j.l.Class instance was left on stack.
The solution is to put wrapping code closer to generation of annotation's
method call itself to guarantee that necessary wrapping will happen.
#KT-9453 Fixed
When synthetic member comes not from the receiver type itself,
but from one of its supertypes it doesn't make sense to subsitute
the member with receiver type, we should obtain relevant supertype
and use it instead.
#KT-16578 Fixed
Set constructor return type in FunctionDescriptorResolver#createConstructorDescriptor
(it seems to be the only place where ClassConstructorDescriptorImpl#initialize(...)
is called, but returnType is not set).
Provide proper dispatch receiver parameter for delegated members.
Use dispatch receiver parameter for delegated members in IR generation
for delegated member body (and check that the receiver has corresponding type).
Incompatibility reason: kotlin-annotation-processing has references to the shaded intellij-core, so, being provided to the unshaded kotlinc from the Kotlin plugin, it throws the AbstractMethodError.
This fixes #KT-16184.
When there is unsuccessful (e.g invisible) result of one kind (static/non-static)
and there is a successful candidate for another kind, choose the latter one.
Note, that we have to postpone commiting trace until we choose one of the results,
otherwise errors of unsuccessful results are reported
TODO: Maybe it makes sense to report all results when all of them are
unsuccessful (NONE_APPLICABLE or something like this)
#KT-16278 Fixed
Expression '1.unaryMinus()' is resolved as Int::unaryMinus call with Int receiver.
However, this expression is implicitly coerced to a different integral type (Byte, Short, Long)
based on results of constant evaluation.
Introduce IMPLICIT_INTEGER_COERCION type operator to handle such cases.
TODO: should we use it for simple constant expressions like '1' and '-1'?
To prevent tests from altering outcomes of the subsequent tests.
Also expose the clearCaches method (in the internal class
ReflectionFactoryImpl) so that it can be used in other places in similar
circumstances
Previously ReflectionTypes.find returned an error class in case a class
is not found in the module dependencies. The problem with this approach
is that each call site should call ErrorUtils.isError on the result and
report an error if needed, in order to stop this type from reaching the
codegen, which can't handle error types.
Now we create a MockClassDescriptor instance instead. It's not an error
class, so it'll be handled correctly in the codegen. Also its scope is
empty and errors are reported on any non-trivial usage (see
MissingDependencyClassChecker), so this approach is not worse than error
classes
#KT-16484 Fixed
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
