Hello,
On Fri, 4 Apr 2025, Bill Wendling wrote:
> > > I don’t have strong preference here. As mentioned by Jacub in a
> > > previous email, these two syntaxes can be distinguished by the number
> > > of arguments of the attribute.
> > >
> > > So for GCC, there should be no issue with either old name of a new
> > > name.
> > > However, I am not sure about CLANG. (Considering the complication
> > > with APPLE’s implementation)
>
> I also don't have a strong opinion on whether we should add new
> '*_expr' attributes. It's pretty easy to determine a single identifier
> from a more complex expression, so it's probably okay to use the
> current name. (I think that's what Apple has been doing internally.)
Differentiating 'identifier' from 'decl' is easy (is first token a type?
-> decl), but 'lone-ident' from 'assignment-expression' requires some
look-ahead. It also always introduces the fun with useless
parentheses: is "(a)" a lone identifier or not? (Normally it's not).
So, your current proposal (lone-ident or declaration) is good, from a
parsing perspective. But anything that somewhat merges lone-ident and
anything in the general assignment-expression syntax tree requires head
scratching, depending on parser implementation.
> My initial thought is that you'd have something like this:
>
> struct Y {
> int n;
> };
>
> struct Z {
> int *ints __attrbiute__((counted_by(struct Y y; y.n)));
> struct Y y;
> };
>
> And it should "just work." I'm not sure if there's an issue with this
> though.
I think it would just work in your proposal, yes. What about the typical
expr-vs-decl woes:
typedef int TY;
struct Z {
int TY;
int *ints __attribute__((counted_by(TY))); // type or lone-ident?
};
when the parser sees the 'TY' token in counted_by (without consuming it):
does it go your first (lone-ident) or your second (decl) branch? (Of
course the second would lead to a syntax error, but we don't know yet,
we've seen the TY token and know that it could refer to a type).
The normal thing a parser would do is to go the second route (and lead to
syntax error). It shouldn't go the first route (lone-ident), as otherwise
you again have a confusion with:
typedef int TY;
struct Z1 {
int *ints __attribute__((counted_by(TY))); // can only be type
int TY;
};
which clearly is a syntax error. (Trying to avoid going the decl route
would also need another look-ahead)
Anyway, I think your current proposal as-is (lone-ident | decl+expression)
is workable.
Ciao,
Michael.
