Proposed semantics for attributes in C++ (and in C?)

[Mark Mitchell <mark at codesourcery dot com>]

We have a number of C++ PRs open around problems with code like this:

  struct S {
    void f();
    virtual void g();
  };

  typedef __attribute__((...)) struct S T;

If the attribute makes any substantive change to S (e.g., changes its 
size, alignment, etc.) then bad things happen.  For example, the member 
functions of "S" have expectations about the layout of "S" that are not 
satisfied if they are called with a "T".  Depending on the attribute and 
circumstances, we do all manner of bad things, including ICE, generate 
wrong code, etc.

For a while now, I've been promising to propose semantics for these 
constructs.  Here is a sketch of the semantics that I think we should 
have.  (I say a sketch because I have not attempted to write standardese.)

All attributes must be classified as either "semantic" or "non-semantic" 
attributes.  A "semantic" attribute is one which might affect 
code-generation in any way.  A "non-semantic" attribute cannot affect 
code-generation.  For example, "used" and "deprecated" are non-semantic 
attributes; there is no way to observe, by looking at an object file, 
whether or not a class has been marked with one of these attributes.  In 
contrast, "packed" is a semantic attribute; the size of a class is 
different depending on whether or not it is "packed".

Any attribute may be applied at the point of definition of a class. 
These attributes (whether semantic or non-semantic) apply to the class. 
 For example, if the class is packed, then the member functions expect 
the "this" pointer to point to the packed class.

A typedef declaration which adds only non-semantic attributes is always 
valid.  As with other typedefs, the typedef declaration creates a new 
name for an existing type.  The type referred to by that name is the 
same type as the original type.  However, the *name* has additional 
properties, implied by the (non-semantic) attributes.  For example, 
using a "deprecated" name for a type results in a deprecation warning. 
But, a function declared to take a parameter with the non-deprecated 
name may be passed a parameter with the "deprecated" name.

A typedef declaration which adds semantic attributes to a class type, 
other than POD classes with no explicitly declared members other than 
data members, to arrays of such classes, to arrays of such arrays, etc., 
is invalid. (POD-ness alone is not satisfactory, as PODs may contain 
function members, and I think dealing with static data members and 
typedef members is not worth the trouble.)

A typedef declaration which adds semantic attributes to a POD class type 
with no function members is valid, but creates an entirely new type, 
different from all other types except others formed by adding the same 
combination of semantic attributes to the same original class type.  In 
the example above, if the typedef adds a semantic attribute, you may not 
pass an "S" to a function expecting a "T" or vice versa.  Neither may 
you pass an "S*" to a function expecting a "T*", without an explicit 
reinterpret_cast.  The name of "T", for linkage purposes, is "T", and 
there is no implicit "T::S" type; instead, however, there is a "T::T" 
type.  (Various consequences follow; for example, typeid(T) gives you a 
type_info object that indicates that the name of the type is "T".) 
References to the original type from within the types of the members of 
the class still refer to the original class.  For example, in:

  struct S {
    char c;
    S* next;
  };
  typedef __attribute__((packed)) S T;

the data member T::next has type "S*", not "T*".

A typedef declaration which adds semantic attributes to a non-class type 
is valid, but again creates an entirely new type.  (We might want a 
special exception to the "entirely new type" rule for the "mode" 
attribute, declaring that "typedef __attribute__((mode(DI))) int LL" is 
equivalent to "typedef long long LL;" on platforms where "long long" has 
DImode.) So,

  typedef S* P;
  typedef __attribute__((...)) P Q;

creates a type "Q" that is incompatible with "S*" if the attribute is 
semantic.  However, the type of "*Q" is still "S".  It is invalid to do 
anything that would require either type_info or a mangled name for "Q", 
including using it as an argument to typeid, thowing an exception of a 
type involving "Q", or declaring a template to take a parameter of a 
type involving "Q".  (We could relax some of these restrictions in 
future, if we add mangling support for attributes.)

A variable declaration involving attributes, like:

  __attribute__((...)) S v;

is treated as syntactic sugar for:

  typedef __attribute__((...)) S T;
  T v;

where T is some invented type name different from all others in the program.

For example given:

  __attribute__((packed)) S v;

the type of "&v" is "__attribute__((packed)) S *", and cannot be passed 
to a function expecting an "S*", but can of course be passed to a 
function expecting an "__attribute__((packed)) S *", or a typedef for 
such a type.

Thoughts?

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713