This is an archive of the discontinued LLVM Phabricator instance.

[Formatters][NFCI] Replace 'is_regex' arguments with an enum.
ClosedPublic

Authored by jgorbe on Sep 2 2022, 5:49 PM.

Details

Summary

Modify SBTypeNameSpecifier and lldb_private::TypeMatcher so they
have an enum value for the type of matching to perform instead of an
m_is_regex boolean value.

This change paves the way for introducing formatter matching based on
the result of a python callback in addition to the existing name-based
matching. See the RFC thread at
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204
for more details.

Diff Detail

Event Timeline

jgorbe created this revision.Sep 2 2022, 5:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 2 2022, 5:49 PM
jgorbe requested review of this revision.Sep 2 2022, 5:49 PM
jgorbe added a comment.Sep 2 2022, 6:54 PM

This is the first step towards something like this big diff: https://reviews.llvm.org/differential/diff/457740/. It's a pretty simple patch, but I would like some feedback about whether you think it's going in the right direction or I should do something else instead.

Here's some more context for that diff linked above. There is, as you could expect, some amount of plumbing so that at callback matching time we have around pointers to the script interpreter, the type of the value, etc, and we can call the callback. But the biggest problem I've found is that there's some logic that is duplicated for each one of {exact, regex} AND for each kind of formatter (summaries, synthetic child providers...). An example of this is TypeCategoryImpl::AnyMatches. Adding a new matching strategy ({exact, regex, callback}) makes the combinatorial problem even worse. So a big chunk of that patch is moving stuff around to try to minimize this problem.

The main refactoring is replacing the existing FormatterContainerPair (that has two members that contain exact match formatters and regex formatters, respectively) with a TieredFormatterContainer which has an array of containers in priority order. The idea is to sink as much of duplicated logic as possible around TypeCategoryImpl (for example, GetFormatAtIndex, GetSummaryAtIndex, GetFilterAtIndex...) into this TieredFormatterContainer to reuse the implementation.

I hope this helps understand the general idea a bit better.

hawkinsw added inline comments.
lldb/include/lldb/DataFormatters/FormattersContainer.h
44–48

I am really intrigued by this entire patchset and just wanted to drop by to help, if I could. I hope that I am not upsetting you by commenting on something so trivial, but it seems like we would want to change the comment for this data member while we are at it?

Again, I think this work is great and I hope I am helping!

jgorbe updated this revision to Diff 459610.Sep 12 2022, 6:17 PM

Updated comment above the declaration of TypeMatcher::m_match_type that referred to the old m_is_regex boolean, to address review feedback

jgorbe marked an inline comment as done.Sep 12 2022, 6:18 PM
jgorbe added inline comments.
lldb/include/lldb/DataFormatters/FormattersContainer.h
44–48

Good catch! I have updated the comment. Thanks for pointing it out :)

jgorbe updated this revision to Diff 459618.Sep 12 2022, 6:33 PM

Fixed mis-spelled member name in comment.

labath accepted this revision.Sep 13 2022, 7:49 AM

This seems in line with what was being discussed. Jim, do you have any thoughts on this?

lldb/include/lldb/lldb-enumerations.h
841

I see the enums in this file use wildly inconsistent styles for the "largest value" enumerator. However, you've picked the one I like the least, because this tends to produce unhandled switch case "kNumFormatterMatchTypes" warnings. If you feel like you need to have a sentinel, I'd recommend going with the eLastFormatterMatchType = <last enum value> pattern (used e.g. in the StateType enum).

This revision is now accepted and ready to land.Sep 13 2022, 7:49 AM
jgorbe added inline comments.Sep 13 2022, 10:18 AM
lldb/include/lldb/lldb-enumerations.h
841

I do want a sentinel because the plan is to replace some hardcoded instances of "check for an exact match and if nothing is found then check for a regex match" with a class that has an array of size kNumFormatterMatchTypes formatter containers, and knows how to do a lookup in priority order. So then I can add another "priority tier" for callback matchers and not add extra logic in a bunch of places.

But I have no strong preference between having a std::array<Container, kNumFormatterMatchTypes> and a std::array<Container, eLastFormatterMatchType + 1>, and I agree the unhandled switch case warnings are annoying. I'll change it shortly.

jgorbe updated this revision to Diff 459845.Sep 13 2022, 12:43 PM

Replaced kNumFormatterMatchTypes with eLastFormatterMatchType to avoid "unhandled enum value" warnings, as suggested by Pavel.

This revision was landed with ongoing or failed builds.Sep 13 2022, 1:00 PM
This revision was automatically updated to reflect the committed changes.