This is more convenient behaviour for debugging with klib-tool than
just failing.
Note that enabling Partial Linkage globally in klib-tool is undesirable,
as it can auto-tweak IR (e.g. when overrides do not match), thus
distorting the rendered IR
^KT-61143 Fixed
Regex OR ('|') has weird precedence rules and previous version of regex
were essentially checking two alternatives:
- kotlin-native-prebuilt-.*-1\.9\.3[0-9](-.+)?
- 2\.0\.0(-.+)?
This is obviously incorrect, but it won't manifest on machines that
already downloaded that artifact to `.konan` via the build without
verification-metadata.xml
Buildscripts that used `ios`-shortcut certainly used
`val iosMain by getting` as well, which will lead to Gradle exception
after migration. Mention in the diagnostic message that one should
replace `by getting` with static accessors
^KT-60734
IDEA sync is always launched with equivalent of `--stacktrace`, so
checking startParameter.showStacktrace is unreliable.
This commit instead mutes printing of stacktraces in sync unless the
internal property is specified. If users want stacktraces, they're
expected to launch Gradle task with `--stacktrace`.
In the extremely rare cases where the stacktrace is needed
*specifically* during IDE sync,
`kotlin.internal.diagnostics.showStacktrace=true` can be used
^KT-61172
- Mention link to docs about templates in warning messages
^KT-60491 Fixed
- Make sure that each warning mentions some way to solve the problem
aside from disabling default template
- Fix small syntactical bug in code sample
- fix incorrect indentation in trimMargin after joinToString
- Use kotl.in in Kotlin12XMppDeprecation
Most of the changes in commit are test-related, as our tests launched
with '-full-stacktrace' by defayult + asserting full stacktrace is
flaky and unreliable
^KT-59774 Fixed
It causes weird failures in functional tests, see KT-60712.
Instead, enumerate all known KGP properties and report only them. Note
that internal properties, unknown to the current version of KGP, won't
be reported. Such cases can appear because of a typo or after migrating
to version of KGP that dropped support for that property. It's not
considered to be a problem at the moment
- Don't use presets (they are deprecated and provoke ERROR, causing
build to fail)
- Drop two JVM targets (cause issues because ambiguous consumable
configuration will be created; proper setup needs disambiguation
attribute, but that's too much for this test)
- Drop jvmWithJava-target (this test case is used in several places
as "just some MPP project", so specific advanced features like
jvmWithJava shouldn't be covered here)
Refer to KT-60745 for proper jvmWithJava support
Test source sets do not participate in the metadata compilations by
default, so the check misses them. This commit just encodes this
behavior into tests, without actually addressing it
KT-60724
- Exclude kotlin-stdlib and kotlin-test from reporting
- kotlin-stdlib wasn't reported, because it doesn't even have Gradle
modular metadata (so no o.j.k.platform.type attribute, and check doesn't
work). This commit explicitly excludes kotlin-stdlib, so that when it
starts publishing Gradle Modular Metadata, nothing would break
- kotlin-test was reported only when it is declared in commonMain,
because we're checking only metadata compilations, and commonTest
isn't compiled to metadata
- Depending on kotlin-test is an odd configuration, but it arises
sometimes (e.g. when people extract some test utilities in a separate
Gradle project)
^KT-58872
- Assert that all dependencies are resolved. Gradle won't fail the build
by default, which might lead to test running in a weird misconfigured
state and producing unreliable results (can be green even though there
are bugs)
- Fix several typos and misconfigurations that were revealed after
adding assertion described above
- CompilationFreeArgsValidator got accidentally unused at some point,
and for now we don't see a reason to enable it back. A proper solution
includes exposing K/N linker options more explicitly via DSL, which
would address the initial problem of passing linker options to compiler
accidentally
- With ComplationFreeArgsValidator removal and migration of
DisabledNativeTargetsReporter to diagnostics infra, AggregateReporter
becomes unused so it can be removed as well
Also demote it from FATAL to ERROR, as FATAL leads to pretty disruptive
UX in IDE (import fails, and you don't get a broken project, which
makes it hard to fix the root cause and declare a target)
- Allow matching substring for 'assertNoDiagnostic' as well
- Better handling of cases when multiple diagnostics with the same ID
are reported (properly look for one 'withSubstring' if provided)
- Introduce 'UsesKotlinDiagnostics' marker-interface for tasks that
want to report diagnostics during their execution
- Introduce 'transparent mode' to collector. When all projects are
evaluated, Collector switches to it and will render all received
diagnostics right away. This allows reporting and rendering diagnostics
that are reported not from tasks, but after evaluation phase (e.g.
diagnostics on resolved dependencies)
^KT-58353 Fixed
This might become an issue if (when) the editable diff window will
be supported, but for now it doesn't make much difference against
which file we compare the actual output.
It's an unfortunate clash between introduction of KotlinPluginLifecycle
and changes in 'deprecationDiagnostics.kt'. It used 'afterEvaluate',
but with KotlinPluginLifecycle later stages are effectively invoked
in multiple nested afterEvaluate, making them invisible for single
afterEvaluate.
Specifically in this case, configuration of metadata compilations for
intermediate source sets is executed in 'FinaliseCompilations' stage,
which is simply not executed by the time checker runs in its single
afterEvaluate.
The fix is trivial -- wrap diagnostic checks runs into launchInStage
^KT-58470 Fixed
Addition of checkers in previous commits lead to CCE when they call
'project.kotlinProjectExtension'. Change in this commit isn't
semantically sound, but allows to repair those tests cheaply
KotlinPlatform*Plugins are plugins from pre 1.3 MPP and shouldn't
be used. The intention was to apply usual 'kotlin("jvm")' and
'kotlin("android")'-plugins, for which KotlinPluginWrapper and
KotlinAndroidPlugin stand respectively
kotlin-gradle-plugin-integration-tests on runtime uses relocated
compiler jars. A special handling is required to support this.
Looks like 'kotlin-gradle-plugin-test-utils' was meant to help
here somehow, but was accidentally broken at some point. It went
unnoticed because not much classes from transitive dependencies
of 'kotlin-gradle-plugin-test-utils' were used.
The change in this commit still leaves a few questions about this
configuration, but at leats it makes it possible to use compiler
classes (e.g. KotlinTestUtils)
Enum-type inherits java.io.Serializable on JVM, so it needs
to be refinement ot avoid TYPE_MISMATCH errors.
Note that for the refinement of Enum-type itself it's necessary
to force refinement of enum-entries, otherwise their supertypes
(and Enum-type specifically) won't be touched
Tests are added on IJ side
^KT-53514
Instead, check the refiner from the DI-container or refiner from
capability of a module descriptor.
The reason is because in the IDE there might be multiple
ResolutionFacades (-> multiple DI-containers -> multiple module
descriptors) for one and the same IDE module, with different refinement
settings.
However, due to how the code is written, it's hard to have
different LanguageVersionSettings for one and the same module.
After this commit the refinement settings are determined by the
moduleDescriptor capabilities, which is much easier to tweak
See usage of that change in Kotlin IDE Plugin (commit is linked to the
YT issue)
^KTIJ-20775
See KT-48291 for example.
The rationale behind the change is that in "findExpectForActual" we want
to find a candidate to be a counterpart for the current (actual)
declaration. Fake overrides can not be a sensible counterpart in that
regard (you can't, nor you should, provide actual for expect which is
FAKE_OVERRIDE)
^KT-48291 Fixed
This is a continuation of KT-46936. This commit removes stdlib-common
from platform-specific source sets of JS/Native targets, as well as
Android and 'jvm { withJava() }'
The tests are made on kotlin-ide side, see the KT-46936 for attached
commits.
^KT-46936
^KT-47695 Fixed
^KT-47604 Fixed
Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
- skip metadata target from importing. That lead to metadata
compilations being imported is well -> some source-sets were
participating in metadata compilations as well -> logic for determining
platforms used to consider metadata compilations as well, adding COMMON
platform to set of platforms
Seems like metadata was never needed in import/IDE, and got there purely
by accident
- Use only targets, actually present in the project, as the default
platform. This is needed mostly for corner-cases/miconfigurations, like
orphan source-sets (source-sets which are created but not included into
any configuraion). Still, for those source-sets the tooling is required
to behave properly; presence of non-existing target can lead to various
issues like showing gutters for test runs, which would fail on launch
(because tests for that target actually do not exist)
^KT-37127 Fixed
Note that previously addSourceSetsToCompilation had logic regarding
platforms. The reason for that is that it was the last place where
default soruce sets of compilations could be distinguished from all
participated source sets.
So, to move that logic, we have to preserve default source sets.
Therefore, this commit introduces 'KotlinCompilation.defaultSourceSets',
and 'ImportingContext.isDefaultSourceSet' method.
The rest is trivial code moving/methods introduction
The resulting code isn't really pretty and likely has non-orthogonal
predicates, this will be cleaned-up in the next commits
Note that LazyClassMemberScope actually has a separate field for
KotlinTypeRefiner, and it might be actually different from the one in
c.kotlinTypeChecker.
The one in c.kotlinTypeChecker is the refiner of *owner* module, i.e. a
module in which the class has been declared. If we have a class Foo :
Expect in common, then the refiner will be from common, and thus it
won't be able to refine supertypes to their platform-dependent values.
The one passed in constructor is actual refiner of dependant-module.
Say, if we're looking at Foo from the point of view of jvmMain, then
we'll create a (view-dependent) LCMS for that, and it will contain
refiner for jvmMain.
It is important to use proper refiner, otherwise the idea of having
"module-dependent view" breaks, and we might suddenly mismatch some
overrides with expect-classes in their signatures.
^KT-44898 Fixed
Set of compiled source sets is already available in
MultiplatformModelImportingContext via
'sourceSetsToParticipatedCompilations.keys', no need to recompute it
^KT-37127
Build dependsOn closure straight away by using KotlinSourceSetProto
instead of building first KotlinSourceSetImpls with incorrect
dependsOn-names, and then discarding it
^KT-37127
Dmitry Savvinov