This adds a data formatter for the implementation of forward_list in
libc++. I've refactored the existing std::list data formatter a bit to
enable more sharing of code (mainly the loop detection stuff).
Details
Diff Detail
- Build Status
Buildable 8342 Build 8342: arc lint + arc unit
Event Timeline
Hey Jim,
I wrote a couple of new libc++ data formatters in july. You seem to be the data formatter owner nowadays. Would you mind taking a look?
Will do. I was sick all last week so I have a bit of a backlog, I'll get to this as soon as I can.
It looks like the behavior of the two derived list classes here are only partially factored out. See the individual comments but it looks like there is a lot more that could be shared.
I also don't think we should change the naming conventions used for these classes piecemeal. If we want to simplify the names and hide the FrontEnds in the source files we should do that wholesale, and not one by one. Otherwise next time I read this file I'm going to waste time wondering why the ForwardListFrontEnd isn't specific to LibCxx whereas the LibcxxStdListSyntheticFrontEnd does seem to be...
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/forward_list/main.cpp | ||
---|---|---|
5 | Some compilers (including clang at other times) will omit debug info for variables that it doesn't see getting used. I usually try to use the variables I'm going to print (call size on them, pass an element to printf, whatever...) to keep this from happening. OTOH, it's nice if compilers don't do that, so maybe relying on their not doing that in our tests is a useful forcing function??? | |
source/Plugins/Language/CPlusPlus/LibCxxList.cpp | ||
141 | I wonder about the decision to move these classes out of lldb_private::formatters. They don't need to be in a globally visible namespace, but all the others are. They also all have a consistent naming convention, which this one doesn't have. This doesn't seem like the sort of thing we should change piecemeal, that will just lead to confusion. Was there some other reason for doing this that I'm missing? | |
153 | Why are these three ivars not in the AbstractListFrontEnd? They appear in both derived classes and seem to be used in the same way. | |
182 | The AbstractFrontEndList has the m_fast_runner and m_slow_runner but they are only reset in the Update for the LibcxxStdListSyntheticFrontEnd, and not here. Is that on purpose? | |
251–260 | This use of the iterators also seems like it should be shared. | |
299–301 | ? | |
303–310 | This bit is done in exactly the same way in the two sub-classes. Could it be moved into the base class Update? |
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/forward_list/main.cpp | ||
---|---|---|
5 | Hmm... I'd say we can leave it like this. I'd be surprised if the compiler can figure out that these declarations are a no-op without very aggressive inlining (which it just won't do at -O0). | |
source/Plugins/Language/CPlusPlus/LibCxxList.cpp | ||
141 | There's no hard reason, but I was trying to make these names more concise I've put them in the anonymous namespace, as llvm coding style encourages that for file-local entities https://llvm.org/docs/CodingStandards.html#anonymous-namespaces. I'd be happy to move the other formatters into the anonymous namespace as well, as I have a couple of other formatters in the pipeline, which already are in the anon namespace. As for the names, if I followed the existing style, this would read something like class LibCxxStdForwardListSyntheticFrontEnd: public LibCxxAbstractListSyntheticFrontEnd which would be formatted horribly, as it does not fit a single line. As these are file-local entities, I think we can be a bit less verbose. I had not renamed the std::list class because of the way I wrote this change (make a copy of the std::list formatter, and then factor out the common code), but you are right that they should follow the same convention. I propose to shorten the name of the other class as well. | |
153 | Good question. I started with two completely distinct implementations and then worked towards merging them. I guess did not finish the job. | |
182 | It doesn't matter since they are re-initialized in HasLoop(), but it does look weird. Fixed it. | |
251–260 | Indeed it can. | |
299–301 | Oops. |
Great, this is much nicer.
source/Plugins/Language/CPlusPlus/LibCxxList.cpp | ||
---|---|---|
141 | The effect on choosing names is one of the many reasons why I don't favor the llvm 80 character restriction. But we're stuck with it so... |
Thanks.
By the way, I have a couple of other patches lined up that you probably did not notice:
https://reviews.llvm.org/D35666
https://reviews.llvm.org/D35615
https://reviews.llvm.org/D35305
Some compilers (including clang at other times) will omit debug info for variables that it doesn't see getting used. I usually try to use the variables I'm going to print (call size on them, pass an element to printf, whatever...) to keep this from happening.
OTOH, it's nice if compilers don't do that, so maybe relying on their not doing that in our tests is a useful forcing function???