5b416cbe77 ci: add job testing cuda13.2 with clang
64dac60df9 ci: Update cuda13.2-x86_64 base image to clang-23
ce3d0af576 Clang/CUDA: Support the llvm23+ offload linker model
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12052
A pure ASM_NASM target has no linker of its own, so emitting
CMAKE_LINKER as <LinkToolExe> broke the build (TRK0005) when it was
not found. Let MSBuild link via the toolset, as MSVC C/CXX targets
already do.
Fixes: #27458
Move some target related enumeration types from `cmStateTypes.h` to a
new header, as these really aren't "state" types. Also, make
`TargetType` a strongly-typed enumeration.
No behavior change:
* Avoid a redundant container lookup before insert by using the result
of a single insert()/emplace() instead of find() followed by insert.
* Replace self-assigning substr() with resize()/pop_back() to shorten
strings in place without an extra allocation.
* Remove a redundant nested condition identical to its enclosing if.
Usage effects describe the relationship between a provider and a
consumer of C++ module interface units. They encompass the flags and
features used to construct BMIs for those units. If the usage effects of
a provider and consumer match, then the provider's BMI may be reused
as-is. If they do not match, then a synthetic target describing the
interface units with the consumer's usage effects applied must be
created.
This commit makes three major changes to how usage effects are reified
in CMake. The first is simple, usage effect hashes now use compile
options and features as the input to their hash instead of the consumer
name. A simply warning flag filter is also applied, mostly to
demonstrate the mechanism. This is the "correct calculation" for usage
effects.
The second is more impactful, usage effects now entirely replace the
compile options of providers with those of consumers if unmatched.
Compile definitions, includes, and links remain unchanged. This is
necessary to ensure successful builds, but is a tricky semantic change.
The third is mostly source-facing, the discovery model for CxxModule
synthetic targets is no longer the global target namespace. Instead,
non-synthetic targets manage their synthetic derivatives. Every target
maintains a usage effect-keyed cache of synthetic targets. When
determining if a synthetic target is necessary, a given provider checks
for compatibility with itself, then for presence in the cache, and if
the cache misses a new synthetic target is created.
Fixes: #27597
575c3dd990 builddb: support builds with empty configuration
3469cc0a46 Tests/CXXModulesCompile: add a test for builddb with empty config
bf442e9deb Tests/CXXModulesCompile: fix `exp-builddb` name references in check scripts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !12101
Add and use a couple helper functions for issuing policy warnings. This
improves consistency and allows some simplification of many call sites.
(One or two instances in particular are greatly simplified.)
Add new diagnostic categories CMD_POLICY and CMD_EXPERIMENTAL, both as
children of CMD_AUTHOR. Use the former when issuing policy warnings. Use
the latter when issuing experimental feature warnings.
GetSwiftModuleName() returns the target name verbatim when
Swift_MODULE_NAME is not set, but hyphens are not valid in Swift
module identifiers. Replace them with underscores so that targets
like swift-syntax get module name swift_syntax automatically.
Issue: #27748
Swift started the trend of piling language-specific target flags in
`cmLocalGenerator::AddLanguageFlags`. Other languages have added their
own under language-specific `Add<Lang>TargetFlags`.
I'm refactoring where Swift piles on its language-specific target flags
to match the pattern other languages are using.
Find places that are currently relying on diagnostic-specific message
types to issue diagnostics and replace these with calls to the new
diagnostic methods.
7ebb5687ab cmGeneratorTarget: use typename for `flag`
4a4986d28a cxxmodules: support command templates for BMI compilation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11871
Some compilers (Clang) warn when using their BMI-only flag with `-c`.
Support a complete template for BMI compilation rather than an
additional flag to support such toolchains.
Fixes: #27600
Since commit 5898c8d2e0 (cxxmodules: Generate per-importer BMIs for
native targets, 2025-12-29, v4.3.0-rc1~43^2~1) we use synthetic targets
to perform per-importer BMI-only compilation of modules even from
in-project targets. However, our BMI-only compile lines are still
generated from the `CMAKE_CXX_COMPILE_OBJECT` rule variable, which
contains `-c` or equivalent. Clang expects `-c` and `--precompile` to
be mutually exclusive, leading to warnings, or errors with `-Werror`.
Follow up commit e5b1a23f27 (c++modules: Revert partial implementation
of per-importer BMIs for 4.3, 2026-02-27, v4.3.0-rc2~9^2) by reverting
the rest of the implementation from the 4.3 release. Work toward fixing
the implementation will proceed in post-4.3 development.
Issue: #25539
Issue: #27600
Issue: #27597
e6a544836b Rust: Update experimental UUID
881faf67e5 Rust: Switch to building .rs files to .rlib instead of native object files
942ddcdd36 Rust: Add support for position independent code
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11686
Each Rust source file given to a target is considered a separate crate
root. There's a concept of a "main crate root", which is the `.rs` file
that is given to the final linker phase in CMake. Other Rust source file
in a target are built as rlib separately.
The project can still build `.rs` files into object files by setting the
Rust_EMIT property on the desired source file.
Move AddHeaderSetVerification, GenerateHeaderSetVerificationFile,
ResolveHeaderLanguage, and GenerateStubForLanguage out of the
monolithic cmGeneratorTarget.cxx into a new split file following
the existing cmGeneratorTarget_*.cxx pattern.