Just fixing a few things I noticed as I am working on another feature for format strings in the prompt: forward decls, adding constexpr constructors, various checks, and unit tests for FormatEntity::Parse and new Definition constructors, etc.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for cleaning this up! Are the if (!sc) ... stuff are missing nullptr checks that affect a normal LLDB session (not sure if we can ever have no SymbolContext) or is this just for the unit test?
Anyway, I have some small inline comments but otherwise this looks pretty good to me.
lldb/include/lldb/Core/FormatEntity.h | ||
---|---|---|
113 | Can you doxygenify this when you anyway touch this code (/// An array of "num_children" Definition entries, before the member)? | |
144 | I believe you could make this far less verbose with delegating constructors and using C++11 default member initializers. | |
lldb/source/Core/FormatEntity.cpp | ||
1765 | One-line if's don't have {} around the body according to LLVM code style (I know this is wrong in a lot of LLDB code, but newer code should follow that style). Just commenting this once but the same thing is happening above/below this change too. |
Thanks - all the comments sound good. I'll upload a new patch.
It seems like the pre-merge check failures are because I incorrectly set the project repo when I first created the revision. I noticed in the build commands here: https://buildkite.com/llvm-project/premerge-checks/builds/28649#b755747b-7673-4dbc-9189-2d6bbcd1fbd3 that the cmake command doesn't include 'lldb' as a project. I was able to repro the error on my Debian machine using those commands, and adding lldb to the cmake command seemed to make them go away (tbh, I'm not familiar enough with the normal output of clang-tidy to be sure)
Is there any way to fix that without creating a new revision or would that be easiest? Thanks, sorry about that.
Missed this earlier - I think you're right, because the formatting code is used for thread/frame lists & information, so there will be a SymbolContext. But one my planned upcoming changes is to use it in the LLDB prompt, where a target might not be available. And it's also more consistent with formatting code for other Entry types.
lldb/source/Core/FormatEntity.cpp | ||
---|---|---|
1560 | Sorry, just caught this. Am uploading a new diff shortly. |
Fix regression introduced by removing return statement in case where we were able to format a function name.
Thanks again for the review! I should have addressed everything with the new diff I just uploaded, but I'm still not sure about the pre-merge check failures because it looks (to me) like the build bot should have "lldb" in its cmake command, although I will freely admit zero experience with LLVM's build infrastructure :-)
Sorry for the delay!
It seems like the pre-merge check failures are because I incorrectly set the project repo when I first created the revision. I noticed in the build commands here: https://buildkite.com/llvm-project/premerge-checks/builds/28649#b755747b-7673-4dbc-9189-2d6bbcd1fbd3 that the cmake command doesn't include 'lldb' as a project. I was able to repro the error on my Debian machine using those commands, and adding lldb to the cmake command seemed to make them go away (tbh, I'm not familiar enough with the normal output of clang-tidy to be sure)
You can ignore the clang-tidy errors as they look indeed like a setup problem on the bot. They won't prevent this from being merged.
I think this looks almost ready beside some small problems (some of which are maybe a bit subjective).
lldb/include/lldb/Core/FormatEntity.h | ||
---|---|---|
111 | You can use \see FormatEntity::Entry::Type and this will be linked in doxygen. | |
119 | Truncated comment? Also thanks for documenting this! | |
lldb/unittests/Core/FormatEntityTest.cpp | ||
23 | I think you can use EXPECT_* in all these tests. | |
154 | You could just use llvm::StringRef here (it's shorter and more descriptive than the auto). |
Thanks for the review - addressed your comments here (I had to rely on Doxygen picking up the type reference automatically because I couldn't get the \see syntax to work correctly, though)
LGTM, thanks for the patch (and especially the unit test)! Some two nits left but feel free to fix those when merging. If you don't have commit access I can also do that, just let me know.
lldb/include/lldb/Core/FormatEntity.h | ||
---|---|---|
120 | Missing period | |
lldb/unittests/Core/FormatEntityTest.cpp | ||
154 | I actually meant llvm::StringRef as the whole type (StringRef references are not really useful as StringRef is already a lightweight String reference) |
lldb/unittests/Core/FormatEntityTest.cpp | ||
---|---|---|
154 | Done - kept it const since StringRef appears to depend on that for some of its methods. I was looking through StringRef (and the use of optionals for something else) and as far as I understand, which could be entirely wrong, it's meant to provide a single interface over unowned character data whether it comes from a std::string or char*, and thought using string_view would be good, as well - is moving to C++17 on the roadmap? I know it's one of those things that everyone is in favor of and wants to do but nobody has time for :) |
Thanks for the review, and apologies for the delay in updating the diffs - seems like I haven't even had an hour to sit down at my dev machine for the past couple weeks, much less actually do any coding :) I don't have commit access, so if you could do that, that would be much appreciated.
Thanks for updating and thanks for the patch! I can land it right now.
lldb/unittests/Core/FormatEntityTest.cpp | ||
---|---|---|
154 | It's on the roadmap but not sure when that will happen. I think that depends on when the interest in having C++17 features is bigger than the pain it will inflict on people stuck on outdated runtime environments that need bootstrapping for C++17. |
clang-tidy: error: 'lldb/lldb-enumerations.h' file not found [clang-diagnostic-error]
not useful