1. 18 Apr, 2016 2 commits
    • Brad King's avatar
      cmState: Remove unused entry point fields from snapshot data · 563bf9dd
      Brad King authored
      This information is now kept in cmMakefile::Backtrace.
    • Brad King's avatar
      cmListFileBacktrace: Refactor storage to provide efficient value semantics · 7c36d206
      Brad King authored
      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
      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.
  2. 15 Apr, 2016 2 commits
    • Brad King's avatar
      cmState: Avoid accumulating snapshot storage for backtraces · 1f6bd8a9
      Brad King authored
      Changes during post-3.3/pre-3.4 development refactored storage of most
      configure-time information, including variable bindings and function
      scopes.  All scopes (even short-lived) were kept persistently for
      possible future debugging features, causing huge accumulated memory
      usage.  This was mostly addressed by commit v3.4.1~4^2 (cmState: Avoid
      accumulating snapshot storage for short-lived scopes, 2015-11-24).
      Since then we still keep short-lived scopes when they are needed for a
      backtrace.  This is because since commit v3.4.0-rc1~378^2
      (cmListFileBacktrace: Implement in terms of cmState::Snapshot,
      2015-05-29) backtraces have been lightweight objects that simply point
      into the snapshot tree.  While the intention of this approach was to
      avoid duplicating the call stack file path strings, the cost turned out
      to be holding on to the entire call stack worth of scope snapshots,
      which is much worse.
      Furthermore, since commit v3.4.0-rc2~1^2 (cmIfCommand: Issue CMP0054
      warning with appropriate context, 2015-10-20) all conditions used in
      `if()` commands hold a backtrace for use in diagnostic messages.  Even
      though the backtrace is short-lived it still causes the scope snapshot
      to be kept.  This means that code like
          foreach(i RANGE 1000000)
      accumulates storage for the function call scope snapshots.
      Fix this by partially reverting commit v3.4.0-rc1~378^2 and saving the
      entire call stack during cmListFileBacktrace construction.  This way
      we can avoid keeping short-lived scope snapshot storage in all cases.
    • Brad King's avatar
      cmState: Add Snapshot method to get bottom of call stack · 18b6676b
      Brad King authored
      The bottom of the call stack is always a long-lived snapshot and can be
      saved for later use with cmOutputConverter.
  3. 12 Apr, 2016 1 commit
  4. 25 Nov, 2015 3 commits
  5. 24 Nov, 2015 2 commits
    • Brad King's avatar
      cmState: Enforce policy scope balancing around variable scopes · 32edac6f
      Brad King authored
      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.
    • Brad King's avatar
      cmState: Skip variable scope snapshots to avoid call stack duplicates · 2e28c619
      Brad King authored
      Since commit v3.4.0-rc1~179^2~1 (cmState: Add a VariableScope snapshot
      type, 2015-08-23) the snapshot stack may have a VariableScopeType entry.
      Skip over these when constructing the call stack, just as we do for
      policy scopes.  Otherwise we report the command causing the variable
      scope to be entered twice (e.g. find_package while loading a package
      version file).
  6. 14 Oct, 2015 1 commit
  7. 13 Oct, 2015 5 commits
  8. 10 Oct, 2015 6 commits
  9. 07 Oct, 2015 1 commit
  10. 11 Sep, 2015 3 commits
  11. 25 Aug, 2015 1 commit
  12. 24 Aug, 2015 3 commits
  13. 23 Aug, 2015 4 commits
  14. 21 Aug, 2015 1 commit
  15. 02 Aug, 2015 3 commits
  16. 01 Aug, 2015 2 commits