aaron.ballman added a comment.
Thank you for working on this! We've (very) slowly been working towards all of
the attribute parsing functions taking a `ParsedAttributesWithRange` so that we
don't lose this information in the AST, and this is a good step in the right
direction towards that.
================
Comment at: clang/lib/Parse/ParseDecl.cpp:820-821
T.consumeClose();
- if (End)
- *End = T.getCloseLocation();
}
----------------
This is a case where we're regressing functionality -- we used to track the
actual end location here, but because this doesn't take a
`ParsedAttributesWithRange`, the end location is lost. Can we rework this to
take a `ParsedAttributesWithRange` instead?
================
Comment at: clang/lib/Parse/ParseDeclCXX.cpp:4661-4662
assert(Tok.is(tok::l_square) && "Not a Microsoft attribute list");
+ // FIXME: ParseMicrosoftAttributes() does not support
+ // ParsedAttributesWithRange.
----------------
Heh, same concern here as above.
================
Comment at: clang/lib/Parse/ParseStmt.cpp:1122
ParsedAttributesWithRange attrs(AttrFactory);
- MaybeParseCXX11Attributes(attrs, nullptr,
+ MaybeParseCXX11Attributes(attrs,
/*MightBeObjCMessageSend*/ true);
----------------
It seems like this could be re-flowed to 80-col?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D120888/new/
https://reviews.llvm.org/D120888
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
