Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reland [lldb] Unify type name matching in FormattersContainer
This was originally reverted because the Linux bots were red after this landed, but it seems that was actually caused by a different commit. I double checked that this works on Linux, so let's reland this on Linux. Summary: FormattersContainer stores LLDB's formatters. It's implemented as a templated map-like data structures that supports any kind of value type and only allows ConstString and RegularExpression as the key types. The keys are used for matching type names (e.g., the ConstString key `std::vector` matches the type with the same name while RegularExpression keys match any type where the RegularExpression instance matches). The fact that a single FormattersContainer can only match either by string comparison or regex matching (depending on the KeyType) causes us to always have two FormatterContainer instances in all the formatting code. This also leads to us having every type name matching logic in LLDB twice. For example, TypeCategory has to implement every method twice (one string matching one, one regex matching one). This patch changes FormattersContainer to instead have a single `TypeMatcher` key that wraps the logic for string-based and regex-based type matching and is now the only possible KeyType for the FormattersContainer. This means that a single FormattersContainer can now match types with both regex and string comparison. To summarize the changes in this patch: * Remove all the `*_Impl` methods from `FormattersContainer` * Instead call the FormatMap functions from `FormattersContainer` with a `TypeMatcher` type that does the respective matching. * Replace `ConstString` with `TypeMatcher` in the few places that directly interact with `FormattersContainer`. I'm working on some follow up patches that I split up because they deserve their own review: * Unify FormatMap and FormattersContainer (they are nearly identical now). * Delete the duplicated half of all the type matching code that can now use one interface. * Propagate TypeMatcher through all the formatter code interfaces instead of always offering two functions for everything. There is one ugly design part that I couldn't get rid of yet and that is that we have to support getting back the string used to construct a `TypeMatcher` later on. The reason for this is that LLDB only supports referencing existing type matchers by just typing their respective input string again (without even supplying if it's a regex or not). Reviewers: davide, mib Reviewed By: mib Subscribers: mgorny, JDevlieghere Differential Revision: https://reviews.llvm.org/D84151
- Loading branch information
Showing
10 changed files
with
302 additions
and
179 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.