Re: Prefix attributes vs. grammar

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Wed, 25 Jul 2001, Mark Mitchell wrote:

> I would actually have preferred that you said "ill-formed, diagnostic
> required", i.e., that argument types to templates may not be attributed.
> That way, we would admit that we don't really know what this means,
> and then people would be prevented from relying on the behavior-du-jour.
> In general, if we must introduce a new language feature without figuring
> out exactly how it interacts with everything else, I think we should 
> explicitly prevent it from interacting with other things.  But, there
> are so many places, in this case, that I have no idea if we could
> actually have done that.

You could yet try banning types with attributes in conjunction with C++
features where attributes cause problems.  This may be like statement
expressions, an extension whose meaning in C is clear (once you have a
precise definition of how attributes bind in syntax and semantics) but
which causes problems when used with C++.

> Related questions include what `typeid' returns for an attributed type.
> If it is the same as the non-attributed variant, then we have the
> case that two typeids will be the same for types that the compiler
> does not think are the same; if it returns a different typeid then
> we have to do more work than we are currently doing.

Probably the same as the non-attributed variant.

> How do conversions from pointer-to-attributed-type and pointer-to-type
> interact?  Do the attributes act like qualifiers where you have
> to be going in the more qualified direction to make the conversion
> without a cast?  That makes sense for things like `noreturn', since
> a non-returning function is a special case of a function.  But

For noreturn, the C front end contains code for this to work the other
way: a pointer to a noreturn function can safely be stored in a generic
function pointer, but storing a generic function in a pointer to noreturn
is unsafe since wrong optimisation might occur if the function does
return.

(noreturn does work on types, if you can get it attached to them -
decl_attributes expects either a FUNCTION_DECL or a pointer-to-function
type.  Unfortunately, various parts of the compiler check
TREE_THIS_VOLATILE on decls, rather than TYPE_VOLATILE on their types (or
better a well-defined TYPE_NORETURN macro), and those types don't get
TYPE_VOLATILE set in decl_attributes - similar to the problem you fixed 
with how ordinary type qualifiers work on decls.)

> not for things like `mode' or `stdcall' where there is no natural
> conversion in either direction.  Does const_cast or static_cast make
> these converions, or do you need reinterpret_casdt?  Egads.

For target attributes, targetm.comp_type_attributes says whether the types
are compatible.  For other attributes, they make random changes to a decl
or type that may get checked by the generic type comparison code, but
don't yet get stored with the decl or type to which they attach (hence the
broken usage of DECL_ASSEMBLER_NAME in format checking).

-- 
Joseph S. Myers
jsm28@cam.ac.uk