1b946dfbfe Merge branch 'backport-4.2-find_package-stack' into find_package-stack
e8ae3645db Merge branch 'backport-4.2-find_package-stack' into find_package-stack
aae02ee60a find_package: Share package information among copies of package stack
a789c21100 Merge branch 'backport-4.2-find_package-stack' into find_package-stack
9387988626 find_package: Save package information only after successfully loading it
561ece2407 cmFindPackageStack: Restore pure value semantics
e935ed22fb find_package: Share package information among copies of package stack
5aa649d5f6 find_package: Save package information only after successfully loading it
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !11887
A stack entry's storage may be shared by other copies, so mutation is
incompatible with value semantics. We've migrated the motivating use
case to another approach.
Revert commit b3873b8272 (cmFindPackageStack: Allow controlled mutation,
2025-07-29, v4.2.0-rc1~438^2) and commit f2bdc2176f (cmStack: New,
mutable stack class, 2025-07-29, v4.2.0-rc1~438^2~1). Record their
parent as a second parent of this commit so `git blame` can see the
original history of the restored content.
Modify cmListFile[Parser] to use cmMakefile rather than cmMessenger as
the interface for issuing messages. This is necessary to provide a
context for diagnostic messages so that they can be controlled via the
diagnostic state (which is not owned by cmMessenger).
Note that we actually bypass the cmMakefile when issuing errors, as
these cannot be disabled (so the diagnostic context doesn't matter), and
we want the calling cmMakefile to still be able to issue its own errors,
which would be suppressed if the cmMakefile has already issued an error.
We would like to record additional information in the find-package
stack, but we don't have the information at the point a stack entry is
created. The most sane way to handle this appears to be making the stack
mutable, at least under specific circumstances. To facilitate this, we
need a mutable stack type.
Refactor cmConstStack into cmStack, with the ability to either allow or
forbid mutation of its data. Re-add cmConstStack as a type alias.
This doesn't yet allow mutating cmFindPackageStack, but it's a necessary
step toward being able to do so.
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
Backtraces may contain non-specific entries (n.b. FromListFilePath in
cmListFileContext). Our prior expectation is that these will ALWAYS
replaced by more specific entries. However, with the previous change to
allow users to create arbitrary stack entries, this is no longer the
case. Modify PrintCallStack to only skip printing these non-specific
entries if they were in fact preceded by a more specific entry.
This, and the functionality of the preceding commit, is intended to be
used for CPS dependency resolution. Because said resolution may fail at
a non-trivial depth, it is important to be able to provide the user with
the path of packages that led to the failure. However, because this
happens through parsing JSON, there is no listfile function to associate
with the stack entries, nor do we attempt to keep track of line numbers
from the JSON. As a result, these entries will never be more specific
than the name of the CPS file whose dependencies we are trying to
locate.
This presents value semantics for a stack of constant values.
Internally it shares ownership to avoid copies. Previously
this was implemented by `cmListFileBacktrace` explicitly,
but the approach can be re-used for other kinds of stacks.
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).
Move backtrace printing functions from `cmListFileBacktrace` over to
`cmMessenger`, their primary caller. Thread `cmMessenger` instances
through APIs needed to update other call sites.
#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.
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
Suppress some cases in `Source/cmGeneratorExpressionNode.cxx` and
`Source/cmUVHandlePtr.h` where a few older compilers require a
user-defined default constructor (with `{}`).
We disabled this in commit 1fe0d72eb6 (clang-tidy: exclude
'misc-noexcept-move-constructor', 2018-09-24) due to false positives.
Restore it and use a NOLINT comment to suppress them instead.
Replace use of raw pointers and explicit reference counting with
`std::shared_ptr<>`. Use a discriminated union to store either the
bottom level or a call/file context in each heap-allocated entry.
This avoids storing a copy of the bottom in every `cmListFileBacktrace`
instance and shrinks the structure to a single `shared_ptr`.
Store both the as-written and lower-case command names and use
the latter to avoid case-insensitive string comparisons.
With this I obtain 2-6% speed increase (on Windows) for the configure
step with no significant changes in memory usage. A case-insensitive
comparison is a lot slower than just calling `==` because the operator
will use things like memcmp, so prefer the latter.
The `cmSystemTools::LowerCase` function allocates a new string each time
it is called, so before this change we were allocating in:
* cmMakefile::Configure two times for each function
(to look for `cmake_minimum_required` and `project`)
* cmMakefile::ExecuteCommand twice by function by calling
cmState::GetCommand and copying the name
Now we are only allocating once by function instead of four.
Brad King
Marc Chevrier
Matthew Woehlke
vvs31415
Sergiu Deitsch
Kitware Robot
Ben Boeckel
Braulio Valdivielso Martinez
Oleksandr Koval
Kyle Edwards
Justin Goshi
Cristian Adam
Regina Pfeifer
Vitaly Stakhovsky
Florian Jacomme
Justin Berger
Daniel Pfeifer