Commit Graph

2 Commits

Author SHA1 Message Date
Brad King 7c36d2067b cmListFileBacktrace: Refactor storage to provide efficient value semantics
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.
2016-04-18 09:21:19 -04:00
Brad King 5d85fb4f40 Fix assertion failure on unmatched function or macro
The fix in commit v3.2.3~3^2 (Fix assertion failure on unmatched foreach
in function, 2015-05-18) broke handling of unmatched non-loop blocks
because it assumed all function blockers removed during error unwinding
were for loops, essentially switching the set of mishandled cases.

The purpose of the loop block push/pop operations is to define a scope
matching the lifetime of the loop function blockers.  Since our function
blockers already have the proper lifetime, simply move the push/pop
operations to their constructor/destructor.

Extend the RunCMake.Syntax test with a case covering this.
2015-06-22 11:41:51 -04:00