[cfe-dev] Storing the NoReturn attribute in Decl nodes.
dgregor at apple.com
Thu Apr 29 09:21:02 PDT 2010
Sent from my iPhone
On Apr 27, 2010, at 9:30 AM, Enea Zaffanella <zaffanella at cs.unipr.it> wrote:
> As we are using clang as a base for a source-code based tool, one of our
> goals is to be able to obtain an AST faithfully representing the
> original source code.
> Among other things, we would like to have a precise description of the
> set of attributes adorning declarations, as well as the specific syntax
> (gnu, cxx0x, microsoft, ...) used to specify them. One simple option to
> encode this syntax-kind info would be to add a bitfield to the Attr base
> class: this will require no additional memory, since Attr already has a
> bitfield of length 1 (Inherited).
> However, we just discovered that, e.g., attribute NoReturn is not stored
> as usual in the list of attributes of the corresponding declaration, but
> it will rather end up in the FunctionType node, encoded as a single
> bit. This would prevent our tool from distinguishing, e.g., between
> void p [[ noreturn ]] ();
> void p() __attribute__ ((__noreturn__));
> Similarly, having it in the FunctionType probably means that there will
> be no Inherited bitfield to query, so that we would not be able to know
> if the attribute was written in this very declaration or in a previous
> declaration of the same function.
> Would it be acceptable if clang (also) adds this attribute to the list
> of attributes of the corresponding declaration, so that it could be
> queried like all other attributes?
Yes, this would be good. Patch pre-approved :)
> Note the we are NOT suggesting modification to FunctionType nodes, which
> will still encode the noreturn bit for any semantic reasoning; we are
> just asking to add some additional syntactic info where it belongs (the
> attributes of the Decl node).
> As an alternative, if you do not want to place it in the Decl node, it
> might be possible to store the NoReturnAttr node in the TypeSourceInfo.
> However, this seems to be an unnecessary complication.
This is too complicated. It belongs on the Decl.
> Enea Zaffanella.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev