[cfe-dev] Storing the NoReturn attribute in Decl nodes.

[Douglas Gregor]

Sent from my iPhone

On Apr 27, 2010, at 9:30 AM, Enea Zaffanella <zaffanella at cs.unipr.it> wrote:

> Hello.
> 
> 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 ]] ();
> and
>    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.

> Regards,
> Enea Zaffanella.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev