This is an archive of the discontinued LLVM Phabricator instance.

1/2: D66174 `RegularExpression` cleanup
ClosedPublic

Authored by jankratochvil on Aug 18 2019, 9:15 AM.

Details

Summary

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.

Diff Detail

Repository
rLLDB LLDB

Event Timeline

jankratochvil created this revision.Aug 18 2019, 9:15 AM
Herald added a project: Restricted Project. · View Herald Transcript
jankratochvil edited the summary of this revision. (Show Details)Aug 18 2019, 9:33 AM
jankratochvil planned changes to this revision.Aug 18 2019, 12:52 PM
jankratochvil retitled this revision from Fix `TestDataFormatterStdList` regression + D66174 follow-up/cleanup to D66174 `RegularExpression` follow-up/cleanup.
jankratochvil edited the summary of this revision. (Show Details)
jankratochvil retitled this revision from D66174 `RegularExpression` follow-up/cleanup to 1/2: D66174 `RegularExpression` follow-up/cleanup.Aug 18 2019, 1:20 PM

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
74

This doesn't sound right, we return the error by value and llvm::StringError stores the error string.

jankratochvil retitled this revision from 1/2: D66174 `RegularExpression` follow-up/cleanup to 1/2: D66174 `RegularExpression` cleanup.
  • Thanks for removing the stale inheritance! (LGTM)

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.

jankratochvil edited the summary of this revision. (Show Details)Aug 19 2019, 7:32 AM

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.

(comment typo fixed)

labath accepted this revision.Aug 19 2019, 7:55 AM

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–320

maybe swap the then and else blocks around to reduce the amount of negation

lldb/source/Utility/RegularExpression.cpp
22–31

Initialize this stuff in the member initializer list?

This revision is now accepted and ready to land.Aug 19 2019, 7:55 AM
JDevlieghere accepted this revision.Aug 19 2019, 8:52 AM

Thanks, Jan. This LGTM with Pavel's comments addressed.

jankratochvil marked 8 inline comments as done.Aug 20 2019, 2:18 AM
jankratochvil added inline comments.
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.

This revision was automatically updated to reflect the committed changes.
jankratochvil marked 2 inline comments as done.

Thanks for the review, I hope my updates for the check-in are fine.