diff options
author | Kristof Umann <dkszelethus@gmail.com> | 2019-08-13 13:09:48 +0000 |
---|---|---|
committer | Kristof Umann <dkszelethus@gmail.com> | 2019-08-13 13:09:48 +0000 |
commit | b9bd6ebe1dca7978b86f27c583e5b471b447108b (patch) | |
tree | 92dae7fe805f1841680a6948bb818da1e1d18947 /lldb/packages/Python/lldbsuite/test/expression_command/unicode-in-variable | |
parent | 7f7b2966f7be82a33543808ae33269199798429b (diff) | |
download | bcm5719-llvm-b9bd6ebe1dca7978b86f27c583e5b471b447108b.tar.gz bcm5719-llvm-b9bd6ebe1dca7978b86f27c583e5b471b447108b.zip |
[analyzer][NFC] Refactoring BugReporter.cpp P1.: Store interesting symbols/regions in a simple set
The goal of this refactoring effort was to better understand how interestingness
was propagated in BugReporter.cpp, which eventually turned out to be a dead end,
but with such a twist, I wouldn't even want to spoil it ahead of time. However,
I did get to learn a lot about how things are working in there.
In these series of patches, as well as cleaning up the code big time, I invite
you to study how BugReporter.cpp operates, and discuss how we could design this
file to reduce the horrible mess that it is.
This patch reverts a great part of rC162028, which holds the title "Allow
multiple PathDiagnosticConsumers to be used with a BugReporter at the same
time.". This, however doesn't imply that there's any need for multiple "layers"
or stacks of interesting symbols and regions, quite the contrary, I would argue
that we would like to generate the same amount of information for all output
types, and only process them differently.
Differential Revision: https://reviews.llvm.org/D65378
llvm-svn: 368689
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/unicode-in-variable')
0 files changed, 0 insertions, 0 deletions