I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the regex.
If this is not considered as a cleanup I will drop this patch and rework D66398 to use the Compile method again.
Details
Diff Detail
- Repository
- rLLDB LLDB
Event Timeline
This code review seems to address a few things. I think it might have been easier to discuss if they were separate patches, but here are my comments:
- Thanks for removing the stale inheritance! (LGTM)
- Thanks for adding the relational operator back. I couldn't find why they were needed (because they weren't used if I understand D66398 correctly). (LGTM)
- While I was doing the transition I considered the lifetime and came to the conclusion that the regex input string (the StringRef) does not need to outlive the regex compilation (regcomp). The interface of llvm::Regex gives the same impression. Is this not correct?
- I'm not a fan of the laziness. Do we really need it? What's the cost of compiling an empty regex for the default constructed object? Now we have to (lazily) recompile the regex after every move, even though an llvm::Regex was designed to be movable.
lldb/include/lldb/Utility/RegularExpression.h | ||
---|---|---|
86 | This doesn't sound right, we return the error by value and llvm::StringError stores the error string. |
Checked it in now as rL369235.
- Thanks for adding the relational operator back. I couldn't find why they were needed (because they weren't used if I understand D66398 correctly). (LGTM)
Yes, you are right the operators were not used. So I have also moved them now to D66398 from this patch.
- While I was doing the transition I considered the lifetime and came to the conclusion that the regex input string (the StringRef) does not need to outlive the regex compilation (regcomp). The interface of llvm::Regex gives the same impression. Is this not correct?
OK, it is correct. So I dropped the core of this patch (+added some lifetime explanatory comments).
- I'm not a fan of the laziness. Do we really need it?
That is no longer a part of this patch.
Just then I find as a good cleanup to drop the Compile method there, don't you? As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the regex.
If this is not considered as a cleanup I will drop this patch and rework D66398 to use the Compile method again.
I am aware the llvm/ part of this patch needs an extra approval and this is why @JDevlieghere had there that:
std::string discarded; return m_regex.isValid(discarded);
Is it complicated to get the llvm/ extension approved? I can quickly drop any parts of this patch not considered as feasible.
I have put there plain m_regex.isValid() instead as with my patch IsValid() is called during every Execute() so IsValid() could become a bottleneck. But then the discarded string is just 32 bytes on stack anyway so it should be cheap enough even without the llvm/ extension.
I agree that it is better to have just one way to initialize the regex object. This looks good to me modulo the llvm parts. I'd suggest just dropping those, or creating a separate patch for that...
lldb/include/lldb/Interpreter/OptionValueRegex.h | ||
---|---|---|
53–55 | The apparent inconsistency here is a pretty good argument against the Compile method imo. | |
lldb/include/lldb/Utility/RegularExpression.h | ||
34 | Null terminated? I hope not.. | |
lldb/source/Commands/CommandObjectFrame.cpp | ||
536–537 | lol | |
lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp | ||
445 | Here I'd just declare a fresh variable in each of the blocks instead of continuously recycling this one. | |
lldb/source/Target/ThreadPlanStepInRange.cpp | ||
317–319 | maybe swap the then and else blocks around to reduce the amount of negation | |
lldb/source/Utility/RegularExpression.cpp | ||
16–19 | Initialize this stuff in the member initializer list? |
lldb/include/lldb/Utility/RegularExpression.h | ||
---|---|---|
34 | Updated+added: + /// An llvm::StringRef that represents the regular expression to compile. + // String is not referenced anymore after the object is constructed. | |
lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp | ||
445 | Rather dropped the variable. |
The apparent inconsistency here is a pretty good argument against the Compile method imo.