This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Clean up uses of UuidCompatibility.h
ClosedPublic

Authored by bulbazord on Jul 28 2023, 10:44 AM.

Details

Summary

This commit does a few related things:

  • Removes unused function uuid_is_null
  • Removes unneeded includes of UuidCompatibility.h
  • Renames UuidCompatibility to AppleUuidCompatibility and adds a comment to clarify intent of header.
  • Moves AppleUuidCompatibility to the include directory

Diff Detail

Event Timeline

bulbazord created this revision.Jul 28 2023, 10:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 28 2023, 10:44 AM
bulbazord requested review of this revision.Jul 28 2023, 10:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 28 2023, 10:44 AM
mib added inline comments.Jul 28 2023, 11:08 AM
lldb/include/lldb/Utility/AppleUuidCompatibility.h
15–16

May be this could be moved to lldb-types.h (if it's even used) so we can remove the whole file ?

bulbazord added inline comments.Jul 28 2023, 12:35 PM
lldb/include/lldb/Utility/AppleUuidCompatibility.h
15–16

I thought about this but I went with this as a safer option. I'm not sure what definition of uuid_t other platforms provide (hopefully the same but I haven't verified). We really only use this definition in two places: ObjectFileMachO and DynamicLoaderMacOSXDYLD. In those places, we just need a compatible definition of uuid_t. Putting it in lldb-types.h would mean we would get that definition everywhere (even if it was already provided by the underlying system, excluding Darwin).

This is fine to me but maybe instead of ifndef apple we could do a if __has_include(<uuid/uuid.h>) and include the system header if it's avail. I must be misreading the patch but it seems like you're changing the filename to AppleUuidCompatbility.h but the two places it's included still call it UuidCompatibility.h.

The uuid_is_null is probably my fault, I think I had something that I had a uuid_t that I didn't want to turn in to a "valid" UUID object when I assigned the bytes, and either I misunderstood the contract or I used the wrong one and once I fixed that, I didn't need the test any more.

This is fine to me but maybe instead of ifndef apple we could do a if __has_include(<uuid/uuid.h>) and include the system header if it's avail. I must be misreading the patch but it seems like you're changing the filename to AppleUuidCompatbility.h but the two places it's included still call it UuidCompatibility.h.

You're not reading it wrong, that was just my mistake. I built this on a Darwin machine so that codepath never ran... Good catch!

The uuid_is_null is probably my fault, I think I had something that I had a uuid_t that I didn't want to turn in to a "valid" UUID object when I assigned the bytes, and either I misunderstood the contract or I used the wrong one and once I fixed that, I didn't need the test any more.

Thanks for the context 👍

bulbazord updated this revision to Diff 545289.Jul 28 2023, 3:16 PM

Fix incorrect includes that @jasonmolenda pointed out

jasonmolenda accepted this revision.Jul 28 2023, 3:16 PM
This revision is now accepted and ready to land.Jul 28 2023, 3:16 PM

This is fine to me but maybe instead of ifndef apple we could do a if __has_include(<uuid/uuid.h>) and include the system header if it's avail.

One reason I decided not to do this is because I don't want to accidentally pull in a different uuid.h on other platforms that may have an incompatible uuid_t definition. I'm not sure what other definition it may have that would make it incompatible, but it might be a headache to figure that out.

This revision was automatically updated to reflect the committed changes.