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.
Since commit ae373e93fb (install(PACKAGE_INFO): Add version and location
to package dependencies, 2025-07-31, v4.2.0-rc1~340^2) we add package
information to the current package's stack entry as it is discovered.
However, a nested package can cause the current package's stack entry to
be replaced by a copy with a new ordering index due to commit c6e6861e63
(install(EXPORT): Export find_dependency() calls, 2023-11-07,
v3.29.0-rc1~439^2~1). Depending on whether imported targets were
created by the current package before finding the nested package, the
`CurrentPackageInfo` pointer is either invalidated, or left pointing at
only one of multiple copies.
Fix this by sharing a single instance of package information with all
copies of the current package's stack entry. Keep a mutable pointer
to the current package's information only while it is still pending.
This also avoids the need to expose mutation from the package stack.
Add a test that exposes the previously-invalidated pointer to dynamic
analysis tools.
Fixes: #27730
Refactor `cmFindPackageStack` to track additional metadata
about <package> found. This includes two new fields,
`Version` and `Location` which correspond to package version and path.
The remaining package information will be implemented in a later commit
As mentioned in the previous commit, 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. This necessitates making the
stack mutable. However, in order to restrict mutation, do not directly
expose the mutable value, and instead arrange for it to be accessible
only via cmFindPackageStackRAII (renamed and extracted from cmMakefile).
This ensures that mutation can only happen while the stack is being
built.
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.
