This is an archive of the discontinued LLVM Phabricator instance.

Rework the way statement attributes are processed; NFC
ClosedPublic

Authored by aaron.ballman on Apr 5 2021, 1:07 PM.

Details

Summary

This changes our approach to processing statement attributes to be more similar to how we process declaration attributes. Namely, ActOnAttributedStmt() now calls ProcessStmtAttributes() instead of vice-versa, and there is now an interface split between building an attributed statement where you already have a list of semantic attributes and building an attributed statement with attributes from the parser.

This should make it easier to support statement attributes that are dependent on a template. In that case, you would add a TransformFooAttr() function in TreeTransform.h to perform the semantic checking (morally similar to how Sema::InstantiateAttrs() already works for declaration attributes) when transforming the semantic attribute at instantiation time.

Diff Detail

Event Timeline

aaron.ballman requested review of this revision.Apr 5 2021, 1:07 PM
aaron.ballman created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptApr 5 2021, 1:07 PM

It is really sad that the attributes can't 'auto transform' themselves. ParsedAttr could (since it has a union of expressions/identifiers), but we don't really seem to have a good way to do it for Attr.

Could we possibly do some table-gen to auto create the 'simple' ones? Basically, any parameter to an attribute that is an 'expr' gets auto-transformed? Similar to how we have handleSimpleAttr, we could have TransformSimpleAttr (or, a generated one).

clang/lib/Sema/TreeTransform.h
1316

Am I missing where the attributes themselves are being rebuilt/transformed??

It is really sad that the attributes can't 'auto transform' themselves. ParsedAttr could (since it has a union of expressions/identifiers), but we don't really seem to have a good way to do it for Attr.

Could we possibly do some table-gen to auto create the 'simple' ones? Basically, any parameter to an attribute that is an 'expr' gets auto-transformed? Similar to how we have handleSimpleAttr, we could have TransformSimpleAttr (or, a generated one).

I think that's likely plausible, though as a follow-up. We have enough declaration attributes with template instantiation that I'd probably start with those and do statement attributes in a second cleanup.

clang/lib/Sema/TreeTransform.h
1316

The transformation happens in TreeTransform<Derived>::TransformAttributedStmt() which calls RebuildAttributedStmt() with the rebuilt attributes.

This revision is now accepted and ready to land.Apr 5 2021, 1:21 PM
rsmith accepted this revision.Apr 5 2021, 1:29 PM
haberman added inline comments.Apr 5 2021, 1:41 PM
clang/lib/Sema/TreeTransform.h
1316

It appears that neither TransformAttributedStmt() nor RebuildAttributedStmt() calls ProcessStmtAttributes(), either directly or transitively, so I'm not seeing where we can run instantiation-time attribute processing logic. What am I missing?

aaron.ballman added inline comments.Apr 5 2021, 2:50 PM
clang/lib/Sema/TreeTransform.h
1316

My thinking is:

  • From handleMustTailAttr() in SemaStmtAttr.cpp, call CheckMustTailAttr() to do the shared semantic checking.
  • Add a TransformMustTailAttr() to TreeTransform, have it call SemaRef.CheckMustTailAttr() as well.
aaron.ballman closed this revision.Apr 5 2021, 2:53 PM

I've commit in 9711118d2edf7aed133616de1eb7f633c263c4b5, thanks for the really quick reviews!

haberman added inline comments.Apr 5 2021, 3:02 PM
clang/lib/Sema/TreeTransform.h
1316

I see. My main concern then is that TransformMustTailAttr() could get access to the ReturnExpr to perform the validation. Right now the MustTailAttr doesn't appear to have any reference to the ReturnExpr, and I don't know how to give it one.

If there is a solution to this problem, I don't have any objection. My main concern is to unblock my change which is a high priority for me and my team.

aaron.ballman added inline comments.Apr 6 2021, 4:23 AM
clang/lib/Sema/TreeTransform.h
1316

I see. My main concern then is that TransformMustTailAttr() could get access to the ReturnExpr to perform the validation. Right now the MustTailAttr doesn't appear to have any reference to the ReturnExpr, and I don't know how to give it one.

I'll add a way for that to happen today or tomorrow and we can iterate from there.