This is an archive of the discontinued LLVM Phabricator instance.

[clang] Enable C++11-style attributes in all language modes
ClosedPublic

Authored by philnik on May 29 2023, 10:23 PM.

Details

Summary

This also ignores and deprecates the -fdouble-square-bracket-attributes command line flag, which seems to not be used anywhere. At least a code search exclusively found mentions of it in documentation: https://sourcegraph.com/search?q=context:global+-fdouble-square-bracket-attributes+-file:clang/*+-file:test/Sema/*+-file:test/Parser/*+-file:test/AST/*+-file:test/Preprocessor/*+-file:test/Misc/*+archived:yes&patternType=standard&sm=0&groupBy=repo

RFC: https://discourse.llvm.org/t/rfc-enable-c-11-c2x-attributes-in-all-standard-modes-as-an-extension-and-remove-fdouble-square-bracket-attributes

This enables [[]] attributes in all C and C++ language modes without warning by default. -Wc++-extensions does warn. GCC has enabled this extension in all C modes since GCC 10.

Diff Detail

Event Timeline

philnik created this revision.May 29 2023, 10:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 29 2023, 10:23 PM
philnik requested review of this revision.May 29 2023, 10:23 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
philnik added inline comments.May 29 2023, 10:28 PM
clang/test/ParserHLSL/group_shared.hlsl
14

Should this also get an extension warning/should attributes be disabled for HLSL?

What is the justification for this? Do other compilers do this? Was there an RFC?

What is the justification for this?

What exactly are you asking for? Why I'd like to back port it? This would make quite a bit of code in libc++ simpler and avoids pit-falls where an attribute works in some place in some version but not in another.

Do other compilers do this?

ICC and NVC++ support this: https://godbolt.org/z/TeMnGdGsY

Was there an RFC?

No. I guess, since you are asking I should write one for this? Only for the removal of -fdouble-square-bracket-attributes, or also for back porting this?

What is the justification for this?

What exactly are you asking for? Why I'd like to back port it? This would make quite a bit of code in libc++ simpler and avoids pit-falls where an attribute works in some place in some version but not in another.

Do other compilers do this?

ICC and NVC++ support this: https://godbolt.org/z/TeMnGdGsY

Was there an RFC?

No. I guess, since you are asking I should write one for this? Only for the removal of -fdouble-square-bracket-attributes, or also for back porting this?

The RFC I would expect for "allow C/C++ style attributes as an extension in previous modes". This is a pretty significant feature to allow as an extension, particularly since our two main alternative compilers (G++/MSVC) don't have this as an extension. I'd be curious how the other C compilers do this as well.

aaron.ballman added subscribers: beanz, Restricted Project.Jun 9 2023, 11:33 AM

No. I guess, since you are asking I should write one for this? Only for the removal of -fdouble-square-bracket-attributes, or also for back porting this?

The RFC I would expect for "allow C/C++ style attributes as an extension in previous modes". This is a pretty significant feature to allow as an extension, particularly since our two main alternative compilers (G++/MSVC) don't have this as an extension. I'd be curious how the other C compilers do this as well.

I think this does warrant an RFC because it impacts both C++ and C, but I'm hoping the RFC is uncontroversial. It's mostly to establish what the use cases are for needing the extension. The feature is conforming as an extension to both languages, and I don't know of any breakage that would come from enabling it by default. I'm not certain whether we want to remove the feature flag immediately or whether we'd like to give one release of warning about it being removed (I'll defer to whatever @MaskRay thinks is reasonable) -- that search is compelling for why it's safe to remove the option, but there's plenty of proprietary code which we don't know about, so it's possible the option is still used. I'd be especially curious to know if anyone is using -fno-double-square-bracket-attributes to disable the feature in a mode where it would otherwise be enabled. I'm adding the clang-vendors group as a subscriber as an early warning that removing the command line option could be a potentially breaking change.

In terms of implementation work, there's still some minor stuff to address. Also, please be sure to also add a release note about the changes, and a potentially breaking entry for removing the command line option (assuming we elect to go that route).

clang/docs/LanguageExtensions.rst
1462

You need to add an entry here as well, as this also extends C.

clang/include/clang/Basic/DiagnosticParseKinds.td
556

Spurious whitespace change.

clang/include/clang/Driver/Options.td
3672

Spurious whitespace change.

clang/lib/Driver/ToolChains/Clang.cpp
1196 ↗(On Diff #526514)

Spurious whitespace change.

clang/lib/Parse/ParseDeclCXX.cpp
4509–4515

Missing the same "not compatible with standards before C2x" warning as for C++ (might want to reword the C++ warning at the same time to fit the newer style)

clang/test/OpenMP/assumes_messages_attr.c
57

Spurious removal.

clang/test/Parser/asm.c
14

Spurious whitespace change

clang/test/Parser/cxx-decl.cpp
316

Huh... I wasn't expecting to see a change here because there's no attribute nearby. Probably fine, but still a bit curious.

322

Spurious change.

clang/test/Parser/objc-attr.m
17

Spurious change.

clang/test/ParserHLSL/group_shared.hlsl
14

CC @beanz

I was wondering the same thing. :-)

clang/test/Sema/attr-type-safety.c
45

Spurious change.

clang/test/Sema/overloadable.c
77

Spurious change.

clang/test/SemaCXX/attr-cxx-disabled.cpp
0

This whole test file can go away -- we no longer let you disable attributes with this extension.

beanz added inline comments.Jun 9 2023, 12:00 PM
clang/test/ParserHLSL/group_shared.hlsl
14

By bug rather than design DXC allows C++ attribute syntax in some places for HLSL.

I'm totally fine with (and prefer) following the rest of the languages here and having HLSL in Clang always allow C++ attributes regardless of language version.

philnik added inline comments.Jun 9 2023, 12:14 PM
clang/test/Parser/cxx-decl.cpp
316

This is probably because of the whitespace trim below.

clang/test/ParserHLSL/group_shared.hlsl
14

Would you like some sort of warning?

beanz added inline comments.Jun 9 2023, 12:32 PM
clang/test/ParserHLSL/group_shared.hlsl
14

Since DXC accepts the syntax without a warning/error I think we're fine without one here. There won't be any portability issues with code that use C++ attributes in HLSL unless they go back to the _extremely_ old compiler that we don't really support anyways.

No. I guess, since you are asking I should write one for this? Only for the removal of -fdouble-square-bracket-attributes, or also for back porting this?

The RFC I would expect for "allow C/C++ style attributes as an extension in previous modes". This is a pretty significant feature to allow as an extension, particularly since our two main alternative compilers (G++/MSVC) don't have this as an extension. I'd be curious how the other C compilers do this as well.

I think this does warrant an RFC because it impacts both C++ and C, but I'm hoping the RFC is uncontroversial. It's mostly to establish what the use cases are for needing the extension. The feature is conforming as an extension to both languages, and I don't know of any breakage that would come from enabling it by default. I'm not certain whether we want to remove the feature flag immediately or whether we'd like to give one release of warning about it being removed (I'll defer to whatever @MaskRay thinks is reasonable) -- that search is compelling for why it's safe to remove the option, but there's plenty of proprietary code which we don't know about, so it's possible the option is still used. I'd be especially curious to know if anyone is using -fno-double-square-bracket-attributes to disable the feature in a mode where it would otherwise be enabled. I'm adding the clang-vendors group as a subscriber as an early warning that removing the command line option could be a potentially breaking change.

In terms of implementation work, there's still some minor stuff to address. Also, please be sure to also add a release note about the changes, and a potentially breaking entry for removing the command line option (assuming we elect to go that route).

If allowing the extension in older language modes deems good, removing -fno-double-square-bracket-attributes seems fine if (and thanks for CCing the clang-vendors group).
If we want to play safely, we can default -fdouble-square-bracket-attributes to true in this patch and remove the option in a follow-up change possibly after some time.

philnik updated this revision to Diff 536620.Jul 2 2023, 12:19 PM
philnik marked 16 inline comments as done.

Address comments

philnik edited the summary of this revision. (Show Details)Jul 2 2023, 12:23 PM
philnik updated this revision to Diff 536623.Jul 2 2023, 1:14 PM
philnik edited the summary of this revision. (Show Details)

Try to fix CI

Aside from the failing precommit CI test case in C, I think this LGTM. I've added @MaskRay as the code owner for the command line option changes in case he's got concerns regarding the deprecation/removal plans.

MaskRay added a comment.EditedJul 10 2023, 2:10 PM

Aside from the failing precommit CI test case in C, I think this LGTM. I've added @MaskRay as the code owner for the command line option changes in case he's got concerns regarding the deprecation/removal plans.

- ``-fdouble-square-bracket-attributes`` has been deprecated. It is ignored now
  and will be removed in CLang 18.

sounds good. (Minor case typo in CLang). As you said in

https://discourse.llvm.org/t/rfc-enable-c-11-c2x-attributes-in-all-standard-modes-as-an-extension-and-remove-fdouble-square-bracket-attributes/71268/2

I’m in support of this idea. I think we should enable the extension unconditionally for Clang 17 with a release note mentioning that -fdouble-square-bracket-attributes will be removed in Clang 18 just as a kindness to users with proprietary code bases that might be using it.

I think a clear summary/commit message should mention that this patch makes [[...]]` available to C++03/C17 and older language standards with no warning by default.

It's also worth calling out that GCC since 10 supports [[]] in all C language modes (AFAICT there is no warning even with gcc -std=c89 -c a.c) (there is a warning -pedantic).

% gcc -c a.c -std=c89  # no warning
% g++ -c a.cc -std=c++03
a.cc:2:1: error: expected unqualified-id before ‘[’ token
    2 | [[nodiscard]] int without_underscores(void);
      | ^
% myclang++ -c a.cc -std=c++03  # no warning with this patch

Reverse ping @philnik :)

The release/17.x branch will be created soon (https://discourse.llvm.org/t/llvm-17-0-0-release-planning-and-update/71762).

I know. I just didn't have the time yet. If you want to make sure it's in 17 feel free to commandeer and fix the last bits.

philnik edited the summary of this revision. (Show Details)Jul 20 2023, 6:58 PM
philnik edited the summary of this revision. (Show Details)
philnik updated this revision to Diff 542743.Jul 20 2023, 7:14 PM
  • Address comments
  • Try to fix CI
  • Rebased
MaskRay accepted this revision.Jul 20 2023, 7:38 PM
This revision is now accepted and ready to land.Jul 20 2023, 7:38 PM
This revision was landed with ongoing or failed builds.Jul 22 2023, 9:34 AM
This revision was automatically updated to reflect the committed changes.
eaeltsin added a subscriber: eaeltsin.EditedAug 7 2023, 12:07 PM

Hi,

Is it a known issue, that clang doesn't compile void foo(char *argv[] [[maybe_unused]]) {} ? The error is error: 'maybe_unused' attribute cannot be applied to types.

https://godbolt.org/z/r9E81cWxh - clang fails, but gcc doesn't.

It looks like there is a lot of oss code of the form void foo(char *argv[] ATTRIBUTE_UNUSED), where ATTRIBUTE_UNUSED was configured to __attribute__((unused)) before this change (thus compiled ok) and to [[maybe_unused]] after this change (thus started to break).

Hi,

Is it a known issue, that clang doesn't compile void foo(char *argv[] [[maybe_unused]]) {} ? The error is error: 'maybe_unused' attribute cannot be applied to types.

https://godbolt.org/z/r9E81cWxh - clang fails, but gcc doesn't.

It looks like there is a lot of oss code of the form void foo(char *argv[] ATTRIBUTE_UNUSED), where ATTRIBUTE_UNUSED was configured to __attribute__((unused)) before this change (thus compiled ok) and to [[maybe_unused]] after this change (thus started to break).

https://eel.is/c++draft/dcl.array#3.sentence-2 -- an attribute in that position appertains to the array type and maybe_unused cannot be applied to types in that way, so I believe Clang's behavior is correct. So I think the C++ attribute behavior is expected, but the change between __attribute__ and [[]] may be catching folks off-guard.