This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add support for checking children in expect_expr
ClosedPublic

Authored by teemperor on Jul 14 2020, 10:08 AM.

Details

Summary

expect_expr currently can't verify the children of the result SBValue.

This patch adds the ability to check them. The idea is to have a CheckValue
class where one can specify what attributes of a SBValue should be checked.
Beside the properties we already check for (summary, type, etc.) this also
has a list of children which is again just a list of CheckValue object (which
can also have children of their own).

The main motivation is to make checking the children no longer based
on error-prone substring checks that allow tests to pass just because
for example the error message contains the expected substrings by accident.

I also expect that we can just have a variant of expect_expr for LLDB's
expression paths (aka 'frame var') feature.

Diff Detail

Event Timeline

teemperor created this revision.Jul 14 2020, 10:08 AM

Do you expect that the order of the children will be important to check?

I'm wondering if the children descriptor shouldn't be a name=>matcher map instead of a list...

Somewhat tying into that is the question whether the list of children should be exhaustive. With a list it makes sense for it to be exhaustive, with a map -- not so much.

But overall, I like the idea.

lldb/packages/Python/lldbsuite/test/lldbtest.py
2445

If we make this a standalone class, could we get rid of the self. in the self.ValueCheck invocations?

2446–2447

the expect_s in the argument names seem unnecessary, and they make the invocations longer. Having the suffix in the property names is probably good.

I'm wondering if the children descriptor shouldn't be a name=>matcher map instead of a list...

Actually the 'name => matcher' map was my first implementation, but that turned out to be not working very well. The problem is that if we design it like that, then one always has to specify a name for this scheme to work. However for many unordered formatters, the names are the indizes of the respective element ([0], [1]), so it would make adding support for not enforcing the child order impossible (without a second API at least). Also having 'name' just being one of many properties one can check (or not) with a ValueCheck seems like a more consistent design.

Do you expect that the order of the children will be important to check?

Somewhat tying into that is the question whether the list of children should be exhaustive. With a list it makes sense for it to be exhaustive, with a map -- not so much.

But overall, I like the idea.

I think ignoring order and making it non-exhaustive should be added, but I just didn't add it in this patch (mostly because the code for that is not as straightforward as this patch). I would say that matching order and exhaustive list should be the default, so if we add it later it shouldn't cause any additional work down the line.

teemperor updated this revision to Diff 281856.Jul 30 2020, 2:50 AM
  • Removed expect_ prefix and make ValueCheck standalone (Thanks Pavel!)
labath accepted this revision.Aug 11 2020, 1:10 AM

I'm wondering if the children descriptor shouldn't be a name=>matcher map instead of a list...

Actually the 'name => matcher' map was my first implementation, but that turned out to be not working very well. The problem is that if we design it like that, then one always has to specify a name for this scheme to work. However for many unordered formatters, the names are the indizes of the respective element ([0], [1]), so it would make adding support for not enforcing the child order impossible (without a second API at least). Also having 'name' just being one of many properties one can check (or not) with a ValueCheck seems like a more consistent design.

Do you expect that the order of the children will be important to check?

Somewhat tying into that is the question whether the list of children should be exhaustive. With a list it makes sense for it to be exhaustive, with a map -- not so much.

But overall, I like the idea.

I think ignoring order and making it non-exhaustive should be added, but I just didn't add it in this patch (mostly because the code for that is not as straightforward as this patch). I would say that matching order and exhaustive list should be the default, so if we add it later it shouldn't cause any additional work down the line.

ok, that makes sense to me.

This revision is now accepted and ready to land.Aug 11 2020, 1:10 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptAug 12 2020, 3:11 AM