ZEPHYR was the first and the last experimental KonanTarget.
As ZEPHYR is now entirely removed from the codebase, the respective code
can be dropped
^KT-64517
Tests were using deprecated targets to produce ERROR-diagnostics.
Replace it with a different diagnostic
(CommonMainOrTestWithDependsOnEdges)
^KT-64517
- Restore PlatformManager constructor (used in buildscripts)
- Replace references to deprecated K/N target with 'else'
Why: buildscripts use these references and compile against older K/N
version (from bootstrap). So they can't be adjusted to newer API,
compilation will fail right away. However, they can't be kept without
changes, because bootstrap tests will fail.
^KT-64517
^KT-66500
We still want to report a readable error on using removed targets rather
than just an "Unknown target"-exception. As previous commits has removed
actual KonanTarget-entries, the check has to be adjusted to work on
plain strings.
^KT-64517
This commit inlines some helper-APIs that became redundant after
dropping deprecated targets.
Full list:
- 'threadsAreAllowed' is always 'true' now
- 'indirectBranchesAreAllowed' is always 'true' now
- 'supportsThreads' is always 'true' now
- 'isMips' is always 'false' now
- 'tlsMode' is always 'LLVMGeneralDynamicTLSModel' now
- 'getBoxRange' is always equal to 'cache.defaultRange' now
- `targetHasAddressDependency` is always true now, so memory order
is always LLVMAtomicOrderingMonotonic now
^KT-64517
Remove plain references to removed KonanTarget or Family entries. All
the changes in this commit are simple removal of some when-branches
on now dropped entries
^KT-64517
Remove sealed subclasses in KonanTarget and associated entries in
Family. This commit doesn't adjust use-sites in the codebase,
see the following commits for that
Implementation notes:
- we use @Deprecated object-stubs in place of previously used sealed
subclasses/enum entries to report readable error instead of plain
UNRESOLVED_REFERENCE on usages of deprecated FQNs.
- these object-stubs *are not* part of the respective sealed
hierarchy/enum class. This is to make it possible to remove
references to them from use-site entirely without breaking exhaustive
'when's
^KT-64517 Fixed
This essentially caches topological sort of dependsOn-dependencies in
FirModuleData. Caching it became more necessary after previous commits
that started to call it quite frequently in
VariableStorageImpl.getStability
Handle case with FirField properly. Previously the code was returning
STABLE_VALUE in that case.
Note that in fact the changed 'when' branch expects only FirJavaField,
as FirFieldImpl should be handled by FirBackingFieldSymbol-check at
the beginning of the method. However, it is impossible to refer to
FirJavaField directly due to module visibility
Enumerate all cases more carefully via exhaustive 'when',
it's more readable and will prevent potential issues in future in case
more subclasses are added.
^KT-58279 Fixed
'getValue' throws if the key isn't present.
Modules without .kt-files might be legitimately absent in inheritorsMap
(see org.jetbrains.kotlin.analysis.low.level.api.fir.compiler.based.SealedClassesInheritorsCaclulatorPreAnalysisHandler)
Previously, such tests were not failing because if a module doesn't
contain .kt-files, then it contains only .java files. And there was
another bug in the tests infra that was essentially folding all the
.java-files in one main-module, effectively shadowing the bug in subject
of this commit.
Previously, the code was calling into
TopDownAnalyzerFacadeForJVM.newModuleSearchScope, which includes
AllJavaSourcesInProjectScope.
This lead to .java-sources being incorrectly attributed to wrong
modules in tests, which, in turn, could've introduced undesired
behaviour around module-dependent checks (e.g. whether a variable
is from the other module and thus can't be smartcasted)
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
Dmitry Savvinov