On Thu, Jul 16, 2026 at 10:16:45AM -0400, Jason Merrill wrote:
> > +The attribute exposes the potentially hidden callsite in the annotated
> > +function, enabling interprocedural optimizations which may not be possible
> > +without the attribute. It is most useful for annotating functions from
> > +dynamically linked libraries, as their bodies are not available during
> > +compilation.
> > +
> > +This attribute is similar to the clang @code{callback} attribute but it is
> > not
> > +compatible with it. The clang implementation allows identifiers as
> > arguments,
> > +marks an unknown argument with -1 and the @code{this} pointer with the
> > index 0.
>
> Hmm, why not support the clang interface instead of exposing our internal
> one? We wouldn't need to change the internal handling of " callback", we
> could translate the clang attribute to our internal attribute in the handle_
> function.
>
> The clang differences described here sound preferable to me from a user
> perspective.
The clang arguments are inconsistent with all the other attributes which
take argument indexes (format, access, alloc_size, nonnull,
null_terminated_string_arg, alloc_align, ...).
And worse, the possibility to use argument names rather than indexes is
a parsing nightmare, does
constexpr int c = 1;
constexpr int d = 2;
[[clang::callback (c, d)]] int foo (void (*a) (void *), void *b, void (*c)
(void *), void *d);
mean callback (1, 2) or callback (3, 4) ?
I think in clang they defer parsing of the arguments until after the
parameters are in scope and if an argument is an identifier, they use it as
argument identifier, otherwise parse it as an expression, but am not sure.
So, in order to mean (1, 2), one would need to write I think (c + 0, d + 0)
or (+c, +d) etc.
They also have __ as meaning the argument doesn't exist.
Jakub
