When the parent of an expression is anonymous, skip adding '.' or '->' before the expression name.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
The source change looks fine, but Greg's the owner of this code so I'll let him say yes for sure.
But don't call the test case "ExpressionPath". The expression parser is different from frame variable. I understand that your intent was "the expression you feed to frame variable" but since we have an "expression" command, and the expressions you feed to it are different from those you feed to "frame variable" overloading the word is only going to cause confusion.
Sure. Would you have a suggestion of how to call it? Maybe something like variable_flat since it is the command used? Also, is it the right place to add it in functionalities or should it be elsewhere?
There's actually already a test for handling C anonymous unions in lang/c/anonymous. That tests the expression parser and some direct SBValue queries at present. It would be appropriate to add your test as another test case in here.
The part of frame variable you are testing here - namely the parsing of these "frame variable" paths, can also be directly accessed with SBValue::GetValueForExpressionPath (aargh, shouldn't have called that "expression" should we? Too late to change now.) Anyway, you can also use that to test more directly if you want.
Hi all
This differential may also be somewhat relevant / of interest, although it deals only with typedefs of untagged struct types.
Best
Luke
See inlined comments.
packages/Python/lldbsuite/test/functionalities/expression_path/TestExpressionPath.py | ||
---|---|---|
44–46 | Shouldn't we also see "s.r[0] = 1" and "s.r[1] = 2" in response to "frame variable s --flat"? | |
47 | Add newline at end of file | |
packages/Python/lldbsuite/test/functionalities/expression_path/main.cpp | ||
27 | Add newline at end of file |
Replaced the test by a new case in lang/c/anonymous test, as suggested by Jim. Is this correct?
Shouldn't we also see "s.r[0] = 1" and "s.r[1] = 2" in response to "frame variable s --flat"?