summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2018-12-19 19:34:24 +0000
committerDavid Blaikie <dblaikie@gmail.com>2018-12-19 19:34:24 +0000
commitac69af7ad6560978883ce08ebf837b49046778c8 (patch)
tree99e73ff33e407568e433bd5e4e6bd9e00736579b /lldb/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py
parent0da49a7ef14b4f0d6fa343b7876209d37f5fe56b (diff)
downloadbcm5719-llvm-ac69af7ad6560978883ce08ebf837b49046778c8.tar.gz
bcm5719-llvm-ac69af7ad6560978883ce08ebf837b49046778c8.zip
llvm-dwarfdump: Improve/fix pretty printing of array dimensions
This is to address post-commit feedback from Paul Robinson on r348954. The original commit misinterprets count and upper bound as the same thing (I thought I saw GCC producing an upper bound the same as Clang's count, but GCC correctly produces an upper bound that's one less than the count (in C, that is, where arrays are zero indexed)). I want to preserve the C-like output for the common case, so in the absence of a lower bound the count (or one greater than the upper bound) is rendered between []. In the trickier cases, where a lower bound is specified, a half-open range is used (eg: lower bound 1, count 2 would be "[1, 3)" and an unknown parts use a '?' (eg: "[1, ?)" or "[?, 7)" or "[?, ? + 3)"). Reviewers: aprantl, probinson, JDevlieghere Differential Revision: https://reviews.llvm.org/D55721 llvm-svn: 349670
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/functionalities/source-map/TestTargetSourceMap.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud