This is an archive of the discontinued LLVM Phabricator instance.

[TableGen] Change assertion information from a tuple to a struct [NFC]
ClosedPublic

Authored by Paul-C-Anagnostopoulos on Apr 20 2021, 7:26 AM.

Details

Summary

This revision changes the representation of assertion information from a tuple to a struct. Assertion information is collected from 'assert' statements.

It makes the code easier to read.

Diff Detail

Event Timeline

Paul-C-Anagnostopoulos requested review of this revision.Apr 20 2021, 7:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 20 2021, 7:26 AM
dblaikie added inline comments.Apr 20 2021, 10:19 AM
llvm/include/llvm/TableGen/Record.h
1479

Could add a comment saying this ctor is here only so you can use make_unique (& I think C++20 will make this work without a user-defined/declared ctor like this (when we eventually adopt C++20, which is a long way off))

Alternatively, since there's only one make_unique, might be just as well to skip the ctor and have the construction code do this:

std::unique_ptr<AssertionInfo> x(new AssertionInfo{Loc, Condition, Message});

(maybe also with a comment there about why make_unique here until C++20 due to the lack of a ctor)

llvm/lib/TableGen/TGParser.cpp
368

This is some very strange/non-idiomatic code. Why are the member accesses qualified like this?

I'd expect this code to look more like: E.Assertion->Loc for instance

3218–3219

You can use 'auto' for the type here, since it's clear from the make_unique on the right what the type of this variable is.

Or you can roll it all into the addEntry call below like this:

addEntry(std::make_unique<Record::AssertionInfo>(ConditionLoc, Condition, Message));

Thanks, @dblaikie. I will incorporated your suggestions and the linties.

llvm/lib/TableGen/TGParser.cpp
368

I was hoping someone would tell me how to simplify this. Why do I need 'AssertionInfo::' this way, but not with '->Loc'?

(also a bunch of clang-format auto-comments on this review, please run this change through clang-format-patch or however else you like to do it to address those comments)

llvm/lib/TableGen/TGParser.cpp
368

I don't think you do? You could write it as (*E.Assertion).Loc as well. It's pretty uncommon to need to scope a member access like you have here (how'd you came across this syntax/end up writing it this way?) - /sometimes/ it may be useful to scope a member function access (x.Base::y()) to access a base member function rather than an override or shadowing in a derived class. (eg: if you want to override a function but delegate some functionality to the orgiinal base function, you could use Base::func() to do that delegation - but very rarely for member variable access)

llvm/lib/TableGen/TGParser.cpp
368

The (*E.Assertion) was just stupid. I did that because *E.Assertion was already there.

For the rest of it. I tried two or three variants until I got it. Let me check . . . nope, don't need the AssertionInfo::. No idea why I ended up with it, since I first assumed I didn't need it.

Twenty years of programming without worrying about pointers has taken its toll.

I have incorporated the lint changes and David's suggestions.

@dblaikie: Could you explain more about what I should say about the AssertionInfo constructor? I don't understand what you meant about the constructor and make_unique().

I have incorporated the lint changes and David's suggestions.

@dblaikie: Could you explain more about what I should say about the AssertionInfo constructor? I don't understand what you meant about the constructor and make_unique().

Oh, something like // user-defined dtor to support std::make_unique, can be removed in C++20 where braced init is supported

craig.topper added inline comments.Apr 22 2021, 10:14 AM
llvm/lib/TableGen/TGParser.cpp
437

Why std::move on the Condition and Message pointers? I don't think that's doing anything.

llvm/lib/TableGen/TGParser.cpp
437

Nope, it isn't. But it was when I slipped back into deleting-pointer-deletes-referent thinking mode. Another result of 20 years of programming in memory-managed languages.

Incorporate latest comments from @dblaikie and @craig.topper.

dblaikie accepted this revision.Apr 23 2021, 1:25 PM

Seems reasonable

This revision is now accepted and ready to land.Apr 23 2021, 1:25 PM
This revision was landed with ongoing or failed builds.Apr 26 2021, 6:58 AM
This revision was automatically updated to reflect the committed changes.