This is an archive of the discontinued LLVM Phabricator instance.

Return actual type from SBType::GetArrayElementType
ClosedPublic

Authored by werat on Oct 28 2020, 10:11 AM.

Details

Summary

SBType::GetArrayElementType should return the actual type, not the canonical type (e.g. int32_t, not the underlying int).

Added a test case to validate the new behavior. I also ran all other tests on Linux (ninja check-lldb), they all pass.

Diff Detail

Event Timeline

werat created this revision.Oct 28 2020, 10:11 AM
Herald added a project: Restricted Project. · View Herald Transcript
werat requested review of this revision.Oct 28 2020, 10:11 AM

This was done on purpose, in commit 902974277d507a149e33487d32e4ba58c41451b6. The comment there is:

Data formatters: Look through array element typedefs

Summary:
Motivation: When formatting an array of typedefed chars, we would like to display the array as a string.

The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup.

So far as I can tell from the discussion in that review, it removed some lower level code that was resolving the typedef too early, then added it at the SB layer to preserve previous behavior, even though that behavior was acknowledged to be not great. There was some promise to come back and fix the SB layer which it doesn't seem like it even happened.

So this patch seems in line with the intent of the previous revision, but Raphael and Greg were the ones active in the review of that older patch, maybe they remember more about this?

jarin accepted this revision.Oct 28 2020, 11:46 AM

The code change looks good to me and it is in line with the change that Raphael and Greg wanted in https://reviews.llvm.org/D72133. As far as I remember, https://reviews.llvm.org/D72133 did not change the previous behavior because I felt that changing API semantics was out of scope of what I wanted to do with the formatters.

Someone else should look at the test. The addition seems to be a bit ad-hoc, but overall reasonable.

This revision is now accepted and ready to land.Oct 28 2020, 11:46 AM
werat added a comment.Oct 29 2020, 9:19 AM

Btw, I don't have commit access, so would be great if someone could land this for me :) (if everything is OK with this patch).

JDevlieghere accepted this revision.Nov 3 2020, 10:31 AM

Btw, I don't have commit access, so would be great if someone could land this for me :) (if everything is OK with this patch).

I'll land this for you once the test suite finishes.

This revision was landed with ongoing or failed builds.Nov 3 2020, 10:54 AM
This revision was automatically updated to reflect the committed changes.