Flag `kotlin.mpp.deprecatedProperties.nowarn` was removed.
Diagnostic could be temporarily suppressed by the:
kotlin.internal.suppressGradlePluginErrors=PreHMPPFlagsError
This property isn't used in IDE import since 222 (KTIJ-21525)
De-facto it was set to false by the code in
hierarchicalStructureMigrationHandling.kt if HMPP is enabled.
And in the future commit we will forbid to disable the HMPP
#KT-48554 In progress
KGP supports only Gradle since 6.8.3, and we run tests on
buildserver only since this version, so we shouldn't try to work if
gradle < 6.8.3.
And in general in MPP plugin we shouldn't support version that is not
supported in KGP
#KT-59278
Old MPP plugins are deprecated for a long time. It is time to report
fatal error for such cases.
Our stdlib still and kotlin-test still using them, so we cannot just
completely remove them, but there is a way to suppress this error:
kotlin.internal.mpp12x.deprecation.suppress=true
Code for the old plugins (together with the remaining testsdata)
will be completely removed once stdlib and kotlin-test
migration completed. ETA: ~ 2.0-Mx
#KT-60553 Verification Pending
During the tests we are using the verbose way of render the diagnostic
meaning, that we are adding the diagnostic id to the diagnostic message.
And we previously didn't have that for one case, so we were unable to
detect in tests that diagnostic with FATAL severity was reported
Android preset functions were moved to a separate interface
because we need to write custom deprecation with ReplaceWith
due KT-57903.
After that we had generated:
- all the K/N preset functions
- jvm functions.
I decided to move jvm function to separate file too,
so the whole division to several files would be somewhat sane.
I kept the KotlinTargetContainerWithPresetFunctions interface to
keep source/binary compatibility for the `android`/ `jvm` preset
functions users
#KT-57903 In Progress
We have [Int|Long|Char]Range classes in 2 different places:
- as separate class-files
- serialized in the kotlin_builtins file
For some reason our Kotlin compiler during the JVM compilation
re-arranging the order of the annotations, so in class file they
will be written in the following order:
- Deprecated
- SinceKotlin
- ExperimentalStdlibApi
But in the kotlin_builtins they will be stored the same way as
in the sources.
We need these 2 way to be synchronized, because stub's in IDE
cares about order.
After this commit IDE test BuiltInDecompilerConsistencyTest is fixed
Maybe in the future we could remove type from the
KtImplicitReceiverValue, because it has ktSymbol, and in theory
that should be enough to create corresponding KtType.
Unfortunately that is not the case for KtClassOrObjectSymbol --
it doesn't have the API for "default" type creation currently.
Regarding code in KtFirCallResolver.kt -- it seems like code there
needs some love in the future. Psi created via custom code there,
because for call x() FIR has receiver x with psi = null
Compiler supposed to generate such method inside the
LocalFileKotlinClass class, but because of the KT-18489 method
getContainingLibrary is not generated. Because of that we potentially
could get AbstractMethodError. In order to fix that we are adding
explicit ovverride in java super class
See IDEA/f53c2114c38f856bdf0ff4d01de9fffeeeb630f2 commit.
In 222+ IDEA usage of the old ErrorUtils (and other classes)
was eliminated, but not in the 211-221 versions.
Relevant Kotlin commit: b5933c70e2
Also, I noticed that stub for createUnresolvedType do not
store arguments into Error type, so I've fixed that too
See IDEA/f53c2114c38f856bdf0ff4d01de9fffeeeb630f2 commit.
In 222+ IDEA usage of the old ErrorUtils (and other classes)
was eliminated, but not in the 211-221 versions.
Relevant Kotlin commit: b5933c70e2
Also, there is usages of UnresolvedType or ErrorType from
the org.jetbrains.kotlin.types package in the safeargs tests,
but it is difficult to restore the compatibility for them.
So, I decided that it is ok to eliminate them in the
`kt-[212|213|221]-*` branches, because it is tests and not
production
:compiler:cli already excluded and :compiler:cli-js have references
to the classes from :cli.
P.s. the excluded list for kotlin-compiler-for-ide artifact is way more
we need to review that and refactor
Please read the description of IDEAPluginsCompatibilityAPI.
Also, you may notice, that Deprecation annotation was removed.
That is because with level ERROR it isn't possible to opt-in
to such API in the legit cases. And with level WARNING it won't be
reported because We have diagnostic with level ERROR about OptIn marker.
Sadly, there is no way to add ReplaceWith to the OptIn marker
Classes like kotlinx.parcelize.Parcelize still used in the Android
plugin in the IDEA, so they should be included into plugin.
Otherwise, we have issues like KTIJ-20220.
#KTIJ-20220 In progress
In recent a39fbd3822 commit
contextReceiverParameters was introduced and new parameter to descriptor
methods was added. Luckily, it is low-level methods enough -- i.e.
they related to new descriptor creation, but still, some compatibility
is broken. This commit fixes usages in the android.nav.safearg that I
have found in the IDEA repo, maybe we will find other after some
compatibility testing.
In the IDEA plugin update there are a code that used system property
"idea.plugins.compatible.build" to calculate the IDEA version
that will be sent to plugin marketplace to download last version of
the plugins. It seems like by some reason setupIdeaStandaloneExecution()
was called from the IDEA thread and because of that idea version was
calculated incorrectly and incorrect version of the plugins was
downloaded.
It is still unclear how the setupIdeaStandaloneExecution() could be
called from the IDEA, so added logging for that.
Relevant issue: MP-3702
Relevant code in the IDEA:
- ApplicationInfoImpl.getPluginsCompatibleBuildAsNumber
Unfortunately, the same testdata is used in IDE, so we should change
testdata in compiler repo and this will affect IDE repo.
This commit is the cherry-pick of commits from IDE repo:
- 4310d730795a53a Fix UltraLightClassLoadingTestGenerated.testEnums():
check by Java file as ULC produces a different but better result
Yan Zhulanow 3/17/21, 8:57 AM
- fbe3c8ba0841f2d4 Disable comparison test for
UltraLightClassSanityTestGenerated.
testAnnotatedPropertyWithSites() Yan Zhulanow 3/18/21, 1:33 PM
- 8fc53027343b5b53 Ignore known (for ages) broken behaviour
of LC Vladimir Dolzhenko 3/19/21, 11:17 PM
All the other annotation classes has abstract modifier.
All nested interfaces has static modifiers.
This commit is not so important for compiler, but it is matter for IDE,
because when we load classes in IDE via
KtLightClassForDecompiledDeclaration -- there are Abstract and Static
on the Container class
Previously, the checker executed for every declaration i.e. every
declaration was considered as expect declaration. Because of that in
some cases this checker could eat 6% of compilation time.
After this commit only declarations marked with expect or actual
are checked. To achieve that, logic, that do reporting about missing
actual modifier was moved to the Actual part.
Please note, that in cases where there is no expect/actual modifier at
all other errors (like redeclaration and missing body on "actual"
declaration) would be reported.
Useful nodes:
- In this checker reportOn is always the same as
descriptor.sourceElement.ktElement. This is because the only case when
it isn't true is PropertyAccessors and they are filtered
- Annotation constructor descriptor isActual == true all the time
- previously for weak incompatible members ACTUAL_MISSING
was not reported
- the logic here is super complicated and crazy, but I don't think that
there is sense to refactor it in the old FE
Previously there were no equals/hashCode implementation.
Because of that subtyping not working properly. That is because in
subtyping we have checks that type constructors are equals
Also toString was added so now it is a bit easier to debug code
involving the KtSymbolBasedAbstractTypeConstructor
In FE10-binding I would like to re-use equal and hashCode mechanics
that was implemented in AbstractTypeConstructor, but I don't need
the supertype implementation, because it already there in FIR
Our test infrastructure (in particular, muting mechanics) rely on
thrown exception during doTestFor function call. But if the
exception happened on background thread, then here we'll get only
TimeOutException but the actual exception won't be reported during
doTestFor call. It would be reported later by the common IDEA test
framework and bypass our mute mechanics
It seems logical to do, because KtFunctionLiteral is KtDeclaration
and KtLambdaExpression is not. Also FirAnonymousFunction use it as
realPsi reference
This way should be used only for old FE wrappers.
It is important that Fir session with custom token should be cached,
because otherwise session with incorrect validity token could be
returned from cache inside analyze call
- KtClassLikeSymbol.primaryConstructor was removed
- Constructors were removed from getCallableMembers because
constructors has no name (or special name `<init>`) and previous
implementation was incorrect
- KtScope.getAllSymbols returns constructors as before. Before it was
like this because of the incorrect implementation of getCallableMembers
- getConstructors has sence only for class scope,
for the rest cases it is empty
This visibility is used for some cases where it isn't allowed to access
to private members of the object from other instances of the same object
because of the type parameter variance.
For almost all clients this visibility is the same as PRIVATE
I was forced to manually do update the following files, because otherwise
they would be ignored according .gitignore settings. Probably they
should be deleted from repo.
Interop/.idea/compiler.xml
Interop/.idea/gradle.xml
Interop/.idea/libraries/Gradle__org_jetbrains_kotlin_kotlin_runtime_1_0_3.xml
Interop/.idea/libraries/Gradle__org_jetbrains_kotlin_kotlin_stdlib_1_0_3.xml
Interop/.idea/modules.xml
Interop/.idea/modules/Indexer/Indexer.iml
Interop/.idea/modules/Runtime/Runtime.iml
Interop/.idea/modules/StubGenerator/StubGenerator.iml
backend.native/backend.native.iml
backend.native/bc.frontend/bc.frontend.iml
backend.native/cli.bc/cli.bc.iml
backend.native/cli.bc/src/org/jetbrains/kotlin/cli/bc/K2Native.kt
backend.native/cli.bc/src/org/jetbrains/kotlin/cli/bc/K2NativeCompilerArguments.kt
backend.native/tests/link/lib/foo.kt
backend.native/tests/link/lib/foo2.kt
backend.native/tests/teamcity-test.property
This is first commit that should't be in kotlin/native master
and should be done only in kotlin repo.
Removed .gitmodule -- because it wasn't used.
.github/* -- because in kotlin repo issues are disabled
.idea/vcs.xml -- because kotlin already has this settings
Basically this is revert of 427e34fe5a commit
This was done due to the KT-39728.
Also we do pick every file separately, because builtIn serializer
unable to filter expects
Originally reportFromPlugin method was introduced to address the problem
with loading of DefaultErrorMessages.Extension vis ServiceLoader.
For some cases this extension was not loaded by ServiceLoader because
classes was loaded via different class loader, common scenario here is
compiler plugins. Ideally we should load such extension point via
getService approach, but unfortunately to do that we need project and
DefaultErrorMessages.render is static method for now.
Also with reportFromPlugin approach is a problem -- all diagnostics
reported via this method has the same id: PLUGIN_[WARNING|ERROR|INFO]
and it isn't possible to suppress only one particular diagnostic.
To bypass this problem the new method
initializeFactoryNamesAndDefaultErrorMessages was introduced.
It basically store DiagnosticRenderer inside DiagnosticFactory.
It is not ideal, because one DiagnosticFactory could have different
renderers for different scenarios -- for compiler and for IDE, but
I think that it is better than reportByPlugin approach.
Stanislav Erokhin