This third step adds support for the 'assert' statement in multiclasses. The statement is now supported at top level and in records, classes, and multiclasses.
@jansvoboda11, once this is pushed, you can add your assertions.
Differential D99751
Add the TableGen assert statement, step 3 Paul-C-Anagnostopoulos on Apr 1 2021, 10:58 AM. Authored by
Details This third step adds support for the 'assert' statement in multiclasses. The statement is now supported at top level and in records, classes, and multiclasses. @jansvoboda11, once this is pushed, you can add your assertions.
Diff Detail
Event TimelineComment Actions Thanks for working on this, Paul! I left a couple of questions/comments inline. Also, it would be nice to go through the clang-format and clang-tidy suggestions and applying those that fit into the TableGen coding style.
Comment Actions I just pushed this revision and I have no idea how. I meant to push the list slice suffix revision, which I did, and somehow this one went along with it. Comment Actions If something's been committed accidentally/without approval, please revert it in a timely manner - if your git client is in some difficult state that might take time to untangle, it may be best to make a new/separate checkout just so you can revert that patch sooner rather than later. Comment Actions The reason I haven't reverted this patch is because I don't feel comfortable doing a revert with the tangled up branches I have. Do you think it's safe to revert the commit on my 'assert' branch even though it is not the topmost commit? Comment Actions I'm not sure what state your branches are in, so I can't say for sure - hence the suggestion to start a new/separate/clean git checkout and revert it there (you could then throw away that checkout, or you could port the patches from your tangled up checkout instead of fixing it (admittedly fixing it's probably a good experience to figure out what went wrong/how to fix it/etc - but it's not uncommon for folks (myself included) to sometimes just blow things away and start again (porting patches by hand) if it's gotten all messed up)) Comment Actions Ah, so I take it from what you're saying that I can start a new branch and then do a revert of an arbitrary commit on it? I guess there is no reason why not. Comment Actions Actually I meant a whole new git checkout ( https://llvm.org/docs/GettingStarted.html#checkout-llvm-from-git ) - but if your current checkout isn't so messed up that you aren't sure a new branch would be enough, then that's great too! Comment Actions Sorry, I didn't realize that by "next step" you were referring to a future patch. I'd like to see my two comments addressed in this (and a prep) patch, instead of in the future.
Comment Actions Could I do the union as a prep patch, but please delay the change to a struct for a subsequent patch? This code is an extension to the previous steps that use a tuple. It's easier to think about the change to a struct as a separate patch. Comment Actions In order to use a union in the RecordsEntry struct, I will have to add an enumerated value that specifies which kind of pointer is in the union. Is that worth the bother? Especially since I believe I'll have to write a special destructor. Comment Actions Would introducing a class hierarchy simplify things? As a reviewer, I'd be much happier approving following patches:
as opposed to approving this patch that (IMO) exacerbates issues in the existing code, with the promise of future patches that will fix things. Maybe I'm being too pedantic. Feel free to ping other reviewers, I don't want to block this patch if I'm being unreasonable. Comment Actions I like your improvements, I just want to do the first one last. It's easier for me to get all the assert-related code in and working, then go back and replace the tuple with a struct when all the relevant code is in one branch. I promise to do it and not just forget about it. It's next on my to-do list. I'm not sure what you mean by introducing a class hierarchy. A RecordsEntry struct already represents just one of the three items that can appear in it. The question here is whether it's worth making it a union if I have to add a discriminator enum and also, I believe, write a custom destructor for it. Right now the discrimination is made simply by checking which item is non-null. |
Shouldn't this be an union {} or llvm::PointerUnion, since it only holds one type at a time? If so, it would be nice to extract into a prep patch.