This is an archive of the discontinued LLVM Phabricator instance.

[clang] Ensure that Attr::Create(Implicit) chooses a valid syntax
ClosedPublic

Authored by rsandifo-arm on Apr 12 2023, 3:05 AM.

Details

Summary

The purpose of this patch and follow-on patches is to ensure that
AttributeCommonInfos always have a syntax that is appropriate for
their kind (i.e. that it matches one of the entries in Attr.td).

The attribute-specific Create and CreateImplicit methods had four
overloads, based on their tail arguments:

(1) no extra arguments
(2) an AttributeCommonInfo
(3) a SourceRange
(4) a SourceRange, a syntax, and (where necessary) a spelling

When (4) had a spelling argument, it defaulted to
SpellingNotCalculated.

One disadvantage of this was that (1) and (3) zero-initialized
the syntax field of the AttributeCommonInfo, which corresponds
to AS_GNU. But AS_GNU isn't always listed as a possibility
in Attr.td.

This patch therefore removes (1) and (3) and instead provides
the same functionality using default arguments on (4) (a bit
like the existing default argument for the spelling).
The default syntax is taken from the attribute's first valid
spelling.

Doing that raises the question: what should happen for attributes
like AlignNatural and CUDAInvalidTarget that are only ever created
implicitly, and so have no source-code manifestation at all?
The patch adds a new AS_Implicit "syntax" for that case.
The patch also removes the syntax argument for these attributes,
since the syntax must always be AS_Implicit.

For similar reasons, the patch removes the syntax argument if
there is exactly one valid spelling.

Doing this means that AttributeCommonInfo no longer needs the
single-argument constructors. It is always given a syntax instead.

Diff Detail

Event Timeline

rsandifo-arm created this revision.Apr 12 2023, 3:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 12 2023, 3:05 AM
rsandifo-arm requested review of this revision.Apr 12 2023, 3:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 12 2023, 3:05 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
erichkeane accepted this revision.Apr 12 2023, 6:21 AM

1 suggestion to catch a few more cases that I think are incorrect, but this is a move in the right direction. Thanks!

clang/include/clang/Basic/AttributeCommonInfo.h
55

If I recall, there was some pretty awful funny business in some attributes, which would explicitly use '0' instead of AS_GNU as implicit. Did you run into any of these?

Would it make sense to make AS_Implicit 'first' here to catch those? Or perhaps make '0' ill-formed (and assert?) and make this '1'?

This revision is now accepted and ready to land.Apr 12 2023, 6:21 AM
rsandifo-arm added inline comments.Apr 12 2023, 10:52 AM
clang/include/clang/Basic/AttributeCommonInfo.h
55

Thanks for the reviews!

Bumping the values to 1 sounds good to me. I've created https://reviews.llvm.org/D148148 for that. I kept AS_GNU first due to:

// Note TableGen depends on the order above.  Do not add or change the order
// without adding related code to TableGen/ClangAttrEmitter.cpp.

(I don't know whether that still applies, but it seemed better to keep the tablegen-sensitive stuff at “one end” of the enum.)

erichkeane added inline comments.Apr 12 2023, 10:53 AM
clang/include/clang/Basic/AttributeCommonInfo.h
55

Thanks! I think that makes sense to me. Just make sure the pre-commit CI still passes before committing this patch stack.