Use clang-tidy's readability-simplify-boolean-expr checker.
After applying the fix-its, revise all changes *very* carefully.
Be aware of false positives and invalid changes.
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* 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.
The clang-format tool can do a good job formatting most code, but
well-organized streaming blocks are best left manually formatted.
Find blocks of the form
os <<
"...\n"
"...\n"
;
using the command
$ git ls-files -z -- Source |
egrep -v -z '^Source/kwsys/' |
xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \
'<<[^\n]*\n(^ *("[^\n]*("|<<|;)$|;)\n){2,}'
Find blocks of the form
os << "...\n"
<< "...\n"
<< "...\n";
using the command
$ git ls-files -z -- Source |
egrep -v -z '^Source/kwsys/' |
xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \
'<<[^\n]*\n(^ *<<[^\n]*(\\n"|<<|;)$\n){2,}'
Surround such blocks with the pair
/* clang-format off */
...
/* clang-format on */
in order to protect them from update by clang-format. Use the C-style
`/*...*/` comments instead of C++-style `//...` comments in order to
prevent them from ever being swallowed by re-formatting of surrounding
comments.
Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first). First
run `clang-format` with the config file:
---
SortIncludes: false
...
Commit the result temporarily. Then run `clang-format` again with:
---
SortIncludes: true
IncludeCategories:
- Regex: 'sys/types.h'
Priority: -1
...
Commit the result temporarily. Start a new branch and cherry-pick the
second commit. Manually resolve conflicts to preserve indentation of
re-ordered includes. This cleans up the include ordering without
changing any other style.
Use the following command to run `clang-format`:
$ git ls-files -z -- \
'*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
egrep -z -v '^Source/cm_sha2' |
egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
egrep -z -v '^Utilities/(KW|cm).*/' |
egrep -z -v '^Tests/Module/GenerateExportHeader' |
egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' |
xargs -0 clang-format -i
This selects source files that do not come from a third-party.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Running the testsuite this function is entered more than 126,000 times. Reorder
the code flow so that a conversion from char* to std::string is only done when
the cache entry is a path one, which happens only ~50 times during the
testsuite.
Since commit v3.4.0-rc1~321^2~2 (Genex: Store a backtrace, not a pointer
to one, 2015-07-08) we treat cmListFileBacktrace instances as
lightweight values. This was true at the time only because the
backtrace information was kept in the cmState snapshot hierarchy.
However, that forced us to accumulate a lot of otherwise short-lived
snapshots just to have the backtrace fields available for reference by
cmListFileBacktrace instances. Recent refactoring made backtrace
instances independent of the snapshot hierarchy to avoid accumulating
short-lived snapshots. This came at the cost of making backtrace values
heavy again, leading to lots of string coying and slower execution.
Fix this by refactoring cmListFileBacktrace to provide value semantics
with efficient shared storage underneath. Teach cmMakefile to maintain
its call stack using an instance of cmListFileBacktrace. This approach
allows the current backtrace to be efficiently saved whenever it is
needed.
Also teach cmListFileBacktrace the notion of a file-level scope. This
is useful for messages about the whole file (e.g. during parsing) that
are not specific to any line within it. Push the CMakeLists.txt scope
for each directory and never pop it. This ensures that we always have
some context information and simplifies cmMakefile::IssueMessage.
Push/pop a file-level scope as each included file is processed. This
supersedes cmParseFileScope and improves diagnostic message context
information in a few places. Fix the corresponding test cases to expect
the improved output.
In commit v2.8.4~32^2~14 (Use cmake::IssueMessage for warnings,
2010-12-07) these warnings became formatted. It is more informative to
give the full call stack with such warnings. Also it is easier to
implement warnings with a full call stack because we do not have to
construct a custom backtrace with only the top.
Rename methods:
* `cmMakefile::Find{ => LocalNonAlias}Target`
* `cmLocalGenerator::Find{ => LocalNonAlias}GeneratorTarget`
These names clarify that they are for directory-local target names
and do not consider alias targets.
Refactoring in commit v3.5.0-rc1~272^2~11 (cmTarget: Implement ALIAS in
terms of name mapping, 2015-10-25) accidentally introduced logic that
assumes ALIAS targets always reference targets in their own directory.
Fix this and add a test case.
The configure-step fix is that `cmMakefile::FindTarget` should not consider
aliases. The purpose of this method is just to look up targets local to
a directory. Since ALIAS and normal targets share a namespace we know a
locally defined target will never collide with an ALIAS target anyway.
The method has 3 call sites, and this change is safe for all of them:
* `cmInstallCommand::HandleTargetsMode`: Rejects aliases before the call.
* `cmFLTKWrapUICommand::FinalPass`: Should never have considered aliases.
* `cmMakefile::FindTargetToUse`: Falls back to a global lookup anyway.
The generate-step fix is that `cmLocalGenerator::FindGeneratorTarget`
should not consider aliases. This method is the generate-step
equivalent to the above. The method has 2 call sites, and this change
is safe for both of them:
* `cmInstallTargetGenerator::Compute`: Never uses an alias target name.
* `cmLocalGenerator::FindGeneratorTargetToUse`: Falls back to global lookup.
Reported-by: Matteo Settenvini <matteo@member.fsf.org>
Re-lookup a variable value when an associated VariableWatch is executed
in cmMakefile::GetDefinition.
This fixes a problem with 'def' sometimes becoming invalid due to memory
reallocation inside an std::vector. In this case, the problem was that
if the call to VariableAccessed actually executed a callback function,
the internal state of the makefile has changed due to the associated
function scope being pushed. This in turn implies that a new
cmDefinitions instance was pushed in cmMakefile::VarTree. As
cmLinkedTree is based on an std::vector, this push can have triggered
reallocation of its internal memory buffer. However, as the value of
'def', which was computed on method entry, actually points to a property
of one of the cmDefinitions instances in cmMakefile::VarTree,
reallocation can invalidate the value of 'def' so that it cannot simply
be returned at the end of the function. The solution implemented here is
to simply lookup the value of 'def' again.
Use cmSystemTools::GetCMakeRoot() which always knows the location of our
resources. Do not depend on CMAKE_ROOT because the user could unset it
from the cache.
Refactoring in commit v3.5.0-rc1~272^2~13 (cmGlobalGenerator: Remove
direct storage of targets, 2015-10-25) replaced an efficient data
structure mapping from target name to cmTarget instance with a linear
search. Lookups through cmGlobalGenerator::FindTarget are done a lot.
Restore the efficient mapping structure with a name indicating its
purpose.
Reported-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
The add_custom_command(TARGET) signature only works for targets defined
in the current directory. Clarify this in the error message when the
target exists but was defined elsewhere.
Inspired-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
We can remove the temporary allocations required for the
default-constructed t_lookup passed into the openstack by refactoring
the code slightly. Furthermore, we use a vector instead of a stack,
since the latter is based on a deque which is not required for a
heap / lifo structure.
This patch removes ~215k allocations.
This hotspot was found with heaptrack.
Make the message suppression more consistent, by adding a check
for the message related CMake variables in cmake::IssueMessage,
which allows callers of IssueMessage other than the message
command to behave as expected. Also added a check for
CMAKE_SUPPRESS_DEVELOPER_WARNINGS in the message command to
mirror the deprecated message type behaviour.
Added a 'force' flag to the cmake::IssueMessage method, to
make the message suppression consistent, when setting the
message related CMake variables directly in a CMake file.
Expand message command tests to cover the AUTHOR_WARNING message
type as well.
Everywhere we use cmMakefile::ScopePushPop to manage variable scopes
also expects policy scopes to be balanced. There is no place that we
use cmMakefile::PolicyPushPop without also using ScopePushPop. Relieve
PolicyPushPop of responsibility for policy scope balance checks by
moving it to ScopePushPop.
The PolicyPushPop constructor arguments and Quiet method were used to
pass non-default arguments to PushPolicy and PopSnapshot, but no clients
use them anymore.
The `PopPolicyBarrier` method is actually responsible for closing any
scope opened by creating a snapshot. Rename it to `PopSnapshot` and add
a comment explaining the purpose of the poilcy-scope-specific part of
the method.
Commit v3.4.0-rc1~494^2~4 (cmMakefile: Add API for elseif to create
backtrace., 2015-05-29) removed the use of cmMakefileCall to push/pop
execution context in favor of a new way to create backtraces.
However, a call to cmMakefile::GetExecutionContext is still invoked to
issue a contextual CMP0054 warning through cmConditionEvaluator. As
the elseif is not part of the call stack, this resulted in trying to
access an empty vector.
Avoid the attempt at getting execution context when evaluating elseif by
constructing a context and backtrace on behalf of the cmConditionEvaluator
in all cases.
2293d43d cmLocalGenerator: Store cmGeneratorTargets.
488723f5 cmMakefile: Store container of cmExportBuildFileGenerators.
15834405 cmGeneratorExpression: Port interface to cmGeneratorTarget.
11165525 cmGeneratorExpression: Port to cmLocalGenerator.
Set a cmLocalGenerator on each instance at compute time. That will
soon be needed to access cmGeneratorTarget instances.
If a cmExportBuildFileGenerator is processed early during configure time as a
result of CMP0024 it must be removed from the list to process later at generate
time.
Add new API for the subdirs command to cmState.
This fixes a regression introduced in commit f716460e (cmMakefile: Move
invokation to initialize snapshot., 2015-10-06).