CMake/Tests/RunCMake/Syntax/FunctionUnmatched-stderr.txt

^CMake Error in FunctionUnmatched.cmake:
  A logical block opening on the line

    .*/Tests/RunCMake/Syntax/FunctionUnmatched.cmake:[0-9]+ \(function\)

  is not closed.
Call Stack \(most recent call first\):
  CMakeLists.txt:[0-9]+ \(include\)$
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-14 18:24:08 +03:00			`^CMake Error in FunctionUnmatched.cmake:`
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 18:31:04 +03:00			`A logical block opening on the line`

			`.*/Tests/RunCMake/Syntax/FunctionUnmatched.cmake:[0-9]+ \(function\)`

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-14 18:24:08 +03:00			`is not closed.`
			`Call Stack \(most recent call first\):`
			`CMakeLists.txt:[0-9]+ \(include\)$`