1. 03 Jun, 2019 1 commit
  2. 18 Apr, 2016 1 commit
    • 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
      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.
      7c36d206
  3. 24 Nov, 2015 1 commit
  4. 01 Aug, 2015 1 commit