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
Add tests to cover these cases:
* run as regular CMake module, in NORMAL_MODE (expected to fail);
* run as CMake script in SCRIPT_MODE (expected to exit with given code);
* run as CMake script that `include()`-s another script with EXIT subcommand;
* run as CMake script which EVAL-uates EXIT subcommand via
`cmake_language(EVAL CODE "<cmake code>")`.
Fixes: #23162
`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
Previously bindings to `std::vector<std::string>` required at least one
value. Some clients have been filtering `keywordsMissingValue` to
support keywords followed by empty lists. Instead, require clients to
specify whether a keyword's list can be empty as part of the binding
type.
The new sub-command writes a string representation of the
current log level to the output variable given to the
sub-command.
Given that the log-level might be set either via the --log-level
command line option or via the CMAKE_MESSAGE_LOG_LEVEL
cache / regular variables, the priority for each of the log level
sources is as follows, with the first one being the highest:
1) --log-level
2) CMAKE_MESSAGE_LOG_LEVEL regular variable
3) CMAKE_MESSAGE_LOG_LEVEL cache variable
4) default log level (STATUS)
Fixes: #23572
Rename the booleans 's_ErrorOccured' and 's_FatalErrorOccured' to
's_ErrorOccurred' and 's_FatalErrorOccurred', respectively.
Rename the getters and setters to 'Get[Fatal]ErrorOccurred' and
'Set[Fatal]ErrorOccurred', and fix all uses across the codebase.
After !6954 got merged, it has become easier for tools to get
full stack-traces for runtime traces of a CMake program. The trace
information already included in the JSON objects (line number, source
file path) allows tools that display these stack traces to print the
CMake source code associated to them. However, CMake commands may
spawn multiple lines, and the JSON information associated to a trace
only contains the line in which the command started, but not the one
in which it ended. If tools want to print stack traces along the
relevant source code, and they want to print the whole command
associated to the stack frame, they will have to implement their own
CMake language parser to know where the command ends.
In order to simplify the life of those who want to write tooling for
CMake, this commit adds a `line_end` field to the json-v1 trace
format. If a given command spans multiple lines, the `line_end` field
will contain the line of the last line spanned by the command (that of
the closing parenthesis associated to the command).
