d76566417e
This patch adds a new matching method for data formatters, in addition to the existing exact typename and regex-based matching. The new method allows users to specify the name of a Python callback function that takes a `SBType` object and decides whether the type is a match or not. Here is an overview of the changes performed: - Add a new `eFormatterMatchCallback` matching type, and logic to handle it in `TypeMatcher` and `SBTypeNameSpecifier`. - Extend `FormattersMatchCandidate` instances with a pointer to the current `ScriptInterpreter` and the `TypeImpl` corresponding to the candidate type, so we can run registered callbacks and pass the type to them. All matcher search functions now receive a `FormattersMatchCandidate` instead of a type name. - Add some glue code to ScriptInterpreterPython and the SWIG bindings to allow calling a formatter matching callback. Most of this code is modeled after the equivalent code for watchpoint callback functions. - Add an API test for the new callback-based matching feature. For more context, please check the RFC thread where this feature was originally discussed: https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11 Differential Revision: https://reviews.llvm.org/D135648
17 lines
282 B
C++
17 lines
282 B
C++
struct Base { int x; };
|
|
struct Derived : public Base { int y; };
|
|
|
|
struct NonDerived { int z; };
|
|
|
|
int main()
|
|
{
|
|
Base base = {1111};
|
|
|
|
Derived derived;
|
|
derived.x = 2222;
|
|
derived.y = 3333;
|
|
|
|
NonDerived nd = {4444};
|
|
return 0; // Set break point at this line.
|
|
}
|