Skip to content

[Eval] Dereference members of a class/struct#21

Merged
kuilpd merged 1 commit intodil-mainfrom
DIL-eval-dereference-member
Feb 20, 2025
Merged

[Eval] Dereference members of a class/struct#21
kuilpd merged 1 commit intodil-mainfrom
DIL-eval-dereference-member

Conversation

@kuilpd
Copy link
Copy Markdown
Collaborator

@kuilpd kuilpd commented Feb 13, 2025

No description provided.

@kuilpd kuilpd requested a review from cmtice February 13, 2025 17:04
@kuilpd
Copy link
Copy Markdown
Collaborator Author

kuilpd commented Feb 13, 2025

I'm not sure, if this is a right fix, because I don't quite understand what is this check, it wasn't there in lldb-eval:

if (node->valobj())

The tests this patch fixes pass this check, so dereferencing the result works. However, for the same tests just calling EvaluateMemberOf also works, because the dereference happens there, which seems like what we're supposed to do, evaluate a member.
For example, this test also passes this if check, but since this also requires evaluating a member, which is not called in this if branch, so the test fails:

(&c_arr[1])->field_

But in these test it works just fine:

ptr_node->value
ptr_node->next->value

@cmtice
Copy link
Copy Markdown
Collaborator

cmtice commented Feb 18, 2025

This fix looks fine. I updated the original lldb-eval code a bit so that sometimes, while parsing, the actual ValueObject for the member field can be identified and bundled into the MemberOf node. In that case there's no point in calling EvaluateMemberOf, as we've already found the member Value Object, so we just return it. But, as you noted, we should check to see if it's a reference type and, if so, dereference it.

@kuilpd kuilpd merged commit b2815f5 into dil-main Feb 20, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants