[PATCH] Treat { 0 } specially for structs with the designated_init attribute.

[Joseph Myers]

On Wed, 24 Jun 2020, Asher Gordon via Gcc-patches wrote:

> I see. So perhaps this isn't the best way to go about implementing
> attribute locations. What do you think would be a better way? Perhaps
> using a DECL_MINIMAL for attributes?

In general, too many things in GCC have the static type "tree".

Ideally identifiers wouldn't be "tree" - there are very few places where 
something can, at runtime, be either an identifier or another kind of 
tree, which makes them a good candidate for a different static type.  But 
there are tricky memory allocation issues around identifiers that make 
changing their representation complicated.

Attributes also have the static type "tree".  They're TREE_LISTs, and 
TREE_LIST is used for many different things and is not a particularly 
efficient type.  Unlike identifiers, there's nothing essential that would 
make it hard to change attributes to have a different static type (which 
could have room to store a location - the parsers know the location for 
each token, it's just that in many cases it ends up getting thrown away 
rather than stored in the datastructures they create) - it would just be a 
large, global change requiring testing across many different targets 
(which should definitely not be combined with any change trying to add a 
new feature - the aim would be that such a change to the internal 
representation does not change how GCC behaves at all).  But each bit of 
that large change should be fairly straightforward.  (I'd guess you might 
have a vec.h vector, each of whose elements is a new attribute type, 
rather than using a linked list with the same type for attributes and 
lists thereof.)

There was at least one previous attempt at changing attributes to have a 
different static type (see commit 4b0b31a65819f64bfeea244bfdcd1a1b8fc3c3cc 
on refs/dead/heads/static-tree-branch), but that was so long ago, and so 
much has changed in GCC since then (including regarding the representation 
of attributes, as part of supporting C++11 attributes and distinguishing 
them from attributes using GNU syntax), that it wouldn't be a useful 
starting point for such a change now.  However, the changes made for 
supporting C++11 attributes would probably make such a change *easier* 
than it was then, because more uses of attributes now go through APIs 
relating specifically to attributes rather than generic TREE_LIST APIs.

-- 
Joseph S. Myers
joseph@codesourcery.com