|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `cmStateSnapshot::RaiseScope` raises a variable in to a parent
directory scope, it uses `GetBuildsystemDirectoryParent` to find the
current top-most scope on the directory's stack. Since commit 3f4e5e8c3d
(cmState: Return end snapshot for GetBuildsystemDirectoryParent.,
2015-09-01, v3.4.0-rc1~100^2~1), that depends on the `DirectoryEnd`
field in the directory's state. However, when variable-only scopes were
added by commit 6954c8936f (cmState: Add a VariableScope snapshot type.,
2015-08-01, v3.4.0-rc1~179^2~1), we neglected to account for the
addition of that field by commit 52dbe654de (cmState: Record the end
position of each directory., 2015-08-01, v3.4.0-rc1~251^2~1).
Prior to commit 44a2f3f332 (Add new flow-control commands for variables
and policies scopes management, 2022-08-05, v3.25.0-rc1~257^2) this
problem went unnoticed because there was no way to have a variable scope
at the top of a directory's stack while processing a subdirectory. Now
the `block()/endblock()` commands enable the behavior, so fix tracking
of a variable scope as the top-most scope in a directory.
Fixes: #24138
|