Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Issue: #26123
VS 17.6 now implements `ScanSourceforModuleDependencies` using the same
`cl /scanDependencies` scanner that our Ninja generator uses. It can
distinguish module internal partitions from module interface units based
on their content. Switch from `CompileAsCppModule` to `CompileAsCpp`
for `CXX_MODULES` sources so that MSBuild can scan and classify them.
Enables the Global Visual Studio Versioned Generator to use two-part toolset versions,
if only one toolset has that version number. For example, (14.32 is specified when
14.32.32142 and 14.32.23242 are installed). This change also add a unique return code
and message if a two-part version is used when multiple matching versions are present.
Fixes: #23933
Revert commit a334f1b906 (VS: Write ZERO_CHECK.proj for VS19 and above,
2021-12-24, v3.24.0-rc1~607^2) and a supporting change from
commit 7219988b00 (VS: Exclude ZERO_CHECK.proj from .sln for
include_external_msproject, 2022-07-15, v3.24.0-rc4~1^2).
The change was made to support `dotnet` tooling in addition to
`msbuild`. However, not having `ZERO_CHECK` in the `.sln` breaks common
interactive workflows. Revert the change for now. Later it can be
re-introduced behind some kind of option that enables `dotnet` support.
Fixes: #23726
Issue: #20227
In `cmGlobalVisualStudio7Generator::WriteTargetsToSolution`, we skip
writing `ZERO_CHECK.proj` to solution file as the check in
`cmGlobalVisualStudioGenerator::IsInSolution` returns `false` for
`ZERO_CHECK`. However, we write ZERO_CHECK to ProjectDependencies for
external projects as there are no checks in
`cmGlobalVisualStudio71Generator::WriteExternalProject`.
Similar to `cmGlobalVisualStudioGenerator::IsInSolution`, we introduce
`IsDepInSolution(const std::string&)` which excludes `ZERO_CHECK.proj`
from being added to sln file for the cases where we have `ZERO_CHECK.proj`.
Fixes: #23708
For VS 19 and above, switch the format of project file to
`VsProjectType::proj` for ZERO_CHECK target. The `ZERO_CHECK.proj`
consists of primitive MSBuild commands only and has no dependency on any
other targets or props files. This proj file is written as a
`ProjectReference` for other targets, but is not written to the sln
file.
Revert commit 925da7d428 (VS: Write ZERO_CHECK.proj for VS19 and above,
2021-12-24). Although its commit message was mistakenly not updated, it
implemented the change for VS 2017 and below too. Since it was merged,
I've discovered several subtle failures in nightly testing with VS 2017.
Revert the change pending further investigation.
The names and formats of our VS flag tables are internal implementation
details. However, some institutions need to maintain support for
non-public VS platforms and toolsets. Provide a hook that their
projects can use to load custom flag table files. This helps avoid
distributing a custom CMake package within such institutions.
Document the hook itself, but explicitly specify that the files the
hook loads are not considered a stable interface.
30c835428f VS: Accept and translate '-T version=' values with three components
58a50a3a0a VS: Fix '-T version=14.28' under VS 16.9
09f59da7f0 cmGlobalVisualStudioVersionedGenerator: Clarify local variable name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5903
CMake accepts the toolset version that is default in the current VS
version by matching the name later VS versions will use for the SxS
props files. It predicts the future name based on the first two
components of the current VS version's default toolset. However, this
heuristic breaks naming the VS 16.8 toolset version 14.28 under VS 16.9
because the latter's default toolset version is 14.28.29910, which did
not increment the second version component (unprecedented in VS).
Fix this by always using the requested version's SxS props file when it
exists, even if it matches the first two components of the current VS
version's default toolset. Also add a special case for the name VS
16.10 will use for VS 16.9's default toolset, so that it can be used
with VS 16.9 too.
Fixes: #21922
#pragma once is a widely supported compiler pragma, even though it is
not part of the C++ standard. Many of the issues keeping #pragma once
from being standardized (distributed filesystems, build farms, hard
links, etc.) do not apply to CMake - it is easy to build CMake on a
single machine. CMake also does not install any header files which can
be consumed by other projects (though cmCPluginAPI.h has been
deliberately omitted from this conversion in case anyone is still using
it.) Finally, #pragma once has been required to build CMake since at
least August 2017 (7f29bbe6 enabled server mode unconditionally, which
had been using #pragma once since September 2016 (b13d3e0d)). The fact
that we now require C++11 filters out old compilers, and it is unlikely
that there is a compiler which supports C++11 but does not support
#pragma once.
VS 16.6 added a `StdOutEncoding` setting for custom commands to tell
MSBuild that the output is encoded as UTF-8. In commit bc877a7e94 (Add
support to indicate UTF-8 custom command pipe output encoding,
2020-04-08) CMake learned to add the setting in anticipation of the VS
16.6 release. However, when 16.6 was released it had a bug in the
implementation of custom tasks with StdOutEncoding enabled that was
exposed by our test suite. In commit 5058fb5401 (VS: Drop
StdOutEncoding with VS 16.6 pending investigation, 2020-05-29) we
disabled the setting pending investigation.
The problem is fixed in VS 16.7 Preview 3, so restore use of the
setting when a VS instance of at least that version is detected.
Fixes: #20769
VS 2017 version 15.8 introduced support for unity builds implemented
in part by the `$(VCTargetsPath)/Microsoft.Cpp.Unity.targets` file.
Do not enable unity builds on VS 15 versions that do not have that file.
Fixes: #20284
