[cfe-dev] [RFC] New attribute `annotate_type`

Tue Oct 12 04:48:52 PDT 2021

On Mon, 11 Oct 2021 at 18:54, Aaron Ballman <aaron at aaronballman.com> wrote:

> On Mon, Oct 11, 2021 at 10:28 AM Martin Brænne via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > I would like to propose a new attribute `annotate_type` that would be
> analogous to the existing `annotate` attribute but for use on types. As for
> `annotate`, the typical use case would be to add annotations to be used by
> static analysis tools.
> >
> > I have a draft patch implementing this attribute (
> https://reviews.llvm.org/D111548), but before it's reviewed I wanted to
> solicit some feedback more broadly on whether people feel this makes sense.
>
> Thanks for the proposal! One question I have is whether we need an
> additional attribute for this instead of reworking [[clang::annotate]]
> so that it applies to either a type or a declaration. Is a separate
> attribute necessary because there may be unfortunate problems with
> using __attribute__((annotate)) as the spelling?
>

Yes, that's exactly the problem. Today, the GNU spelling can be applied
<https://godbolt.org/z/sK8hxc8z4> both before and after the type name:

  __attribute__((annotate("foo"))) int i1;
  int __attribute__((annotate("foo"))) i2;

We would need to reinterpret the second variant to refer (or "appertain")
to the decl-specifier-seq, not to the declaration (which is, IIUC, what the
C++ standard would prescribe if this was a C++ attribute). But as it's
possible that this variant is already being used "in the wild" with the
intent that it should refer to the declaration, I think this isn't
something we can change.

Hence, the practical solution seems to be to introduce a separate attribute
for types, for which it is then unambiguous what it should apply to.

As a side note, IIUC, Clang currently more generally lumps GNU attributes
that occur in these two positions together, right? I'm looking
at Parser::ParseSimpleDeclaration(), specifically this line
<https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L1818>
:

DS.takeAttributesFrom(Attrs);

For C++ attributes, I believe this would not be correct, but that's not
(currently) a concern because AFAICT Clang currently doesn't allow C++
attributes to occur after a decl-specifier-seq at all (because, I presume,
Clang doesn't yet support any C++ attributes that can occur in this
position). This also means that if we want to use the proposed
`annotate_type` attribute in this position, we have to use the GNU
spelling. This is an unfortunate niggle, but teaching Clang to correctly
process C++ attributes in this position seems like a non-trivial
undertaking because it would require us to treat GNU spellings and C++
spellings differently in Parser::ParseSimpleDeclaration(), which seems like
it would be a bit of a headache.

What kind of type semantic impacts does this attribute have on the
> type identity for things like overloading, name mangling, type
> conversion, etc?
>

Good point. The intent is that the attribute should have no impact.
Anything else would be pretty problematic from a portability point of view
because other compilers will simply ignore the attribute -- so if it had an
effect on the type system in Clang, that could cause other compilers to
generate different code.

Also, one problem here is -- [[clang::annotate]] isn't just used for
> the static analyzer, it's also something that can be used by backend
> tools (for example, when using attribute plugins).

It's good that you bring this up because I'm actually also thinking about
extending ParsedAttrInfo to handle type attributes (with a new
handleTypeAttribute() function as an analog to handleDeclAttribute()). The
proposed annotate_type attribute would then also be a natural candidate for
an attribute that the new handleTypeAttribute() could add to types.

Is this the concern that you had here or were you thinking about something
different?

> Do we need to
> consider what information should be lowered to LLVM IR when this new
> attribute appears on a type?
>
> Thanks!
>

My intent was that this should have no effect on code generation.

Lowering annotations on declarations to LLVM IR has some obvious use cases,
but for annotations on types it's less obvious how it would be useful to
lower these to IR (and also less obvious to me how one would represent
these). (Did you have anything specific in mind here?)

This could actually make another case for why we have two different
attributes, because that would make the distinction clearer that we're
doing code generation for one but not the other.

Thanks,

Martin

> ~Aaron
>
> >
> > Thanks,
> >
> > Martin
> >
> > --
> >
> > Martin Brænne
> >
> > Software Engineer
> >
> > mboehme at google.com
> >
> >
> > Google Germany GmbH
> > Erika-Mann-Straße 33
> > 80363 München
> >
> > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> >
> > Registergericht und -nummer: Hamburg, HRB 86891
> >
> > Sitz der Gesellschaft: Hamburg
> >
> >
> > Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
> leiten Sie diese bitte nicht weiter, informieren Sie den Absender und
> löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
> >
> >
> >
> > This e-mail is confidential. If you are not the right addressee please
> do not forward it, please inform the sender, and please erase this e-mail
> including any attachments. Thanks.
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

-- 

Martin *Brænne*

Software Engineer

mboehme at google.com

Google Germany GmbH
Erika-Mann-Straße 33
80363 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und
löschen Sie die E-Mail und alle Anhänge. Vielen Dank.

This e-mail is confidential. If you are not the right addressee please do
not forward it, please inform the sender, and please erase this e-mail
including any attachments. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211012/6af90221/attachment-0001.html>