Fix #23224 - ImportC: parse C23 [[...]] attribute-specifier-sequences

[PetarKirov]

Part of #23223. Adds C23 [[...]] attribute-specifier-sequence support to ImportC, on
top of a small standalone fix for a pre-existing deprecation-diagnostic bug that the
feature depends on.

N3220 (C23's final spec working draft) can be found here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

Commits

Fix #23241 — duplicate deprecation message for enum member accessed by name
A deprecated enum member accessed by its unqualified name (an anonymous enum member,
one brought into scope via with, or — with this PR — an ImportC enumerator) reported
the deprecation twice: once during name resolution and again in getVarExp(), which
performs the deprecated/disabled checks itself. The enum member is now checked once.

Fix #23224 — ImportC: parse C23 [[...]] attribute-specifier-sequences
ImportC now understands the C23 attribute syntax (C23 §6.7.13) wherever a GNU
__attribute__ is accepted: on declarations, pointers, struct/union/enum tags, struct
members, enumerators, function parameters, and statements. It mirrors the existing
GNU-attribute parser and funnels into the same Specifier machinery (no new AST nodes).

• [[deprecated]] / [[deprecated("msg")]] (§6.7.13.5) and [[noreturn]] /
  [[_Noreturn]] (§6.7.13.7) map to their D equivalents; [[deprecated]] on an
  enumerator deprecates the D enum member.
• [[nodiscard]], [[maybe_unused]], [[fallthrough]], [[unsequenced]],
  [[reproducible]], vendor-prefixed (gnu::, clang::) and unknown attributes are
  accepted and ignored.
• The __attr__ spelling is treated identically to attr (§6.7.13.1).

[[noreturn]] maps to the existing FuncDeclaration.noreturn flag (a backend SFLexit
codegen hint), consistent with how _Noreturn / __attribute__((noreturn)) already
behave (#12966) — not the D noreturn type, since C's noreturn is advisory and may
apply to non-void / value-returning functions.

Tests

• compilable/c23attributes.c — every attribute in every accepted position.
• compilable/testc23attributes.d — imports the above and uses __traits(isDeprecated)
  to verify the D-observable effects (functions and enum members).
• fail_compilation/c23attributes_deprecated.c — [[deprecated]] fires under -de.
• compilable/deprecated_enum_member.d — the Duplicate deprecation message when a deprecated enum member is accessed by name #23241 regression (single diagnostic).

The full ImportC test suite and all deprecation-output tests pass locally.

[dlang-bot]

Thanks for your pull request, @PetarKirov!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• In preparation for migrating from Bugzilla to GitHub Issues, the issue reference syntax has changed. Please add the word "Bugzilla" to issue references. For example, Fix Bugzilla Issue 12345 or Fix Bugzilla 12345.(Reminder: the edit needs to be done in the Git commit message, not the GitHub pull request.)

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#23242"

[dkorpel]

Before we start merging all this AI generated code in dmd, I'd like the whole C23 operation to be justified and approved. #23223 (comment)

[PetarKirov]

I can open PRs for some of the other small C23 features, but I also prefer waiting for approval, before wasting effort.

all this AI generated code

Although I didn't have opportunity to contribute to D (lack of time) in recent years, I still deeply care about its success. This includes both the maintenance and the reputation (e.g. who would want to use a project merging unreviewed vibe-slop).

I've spent a lot of care on extracting the relevant parts of the C23 spec, iterating on the tests (that's how I found the bug fixed by the first commit) and reviewing the changes to cparse.d and ‎expressionsem.d‎. It certainly wasn't just a one shot "implement this feature, make no mistakes!" 😄

[dkorpel]

Code looks good logically, but in an overly verbose AI style. Like, do we really need 62 mentions of C23 6.7.13?

Please fix the duplicate deprecation message issue in a separate PR.

[ibuclaw]

It might even be relevant to reconsider the approach taken to implement this too.

This is currently doing quite a lot of heavy lifting in the parser just to support [[ some text ]] - "normalizing" (whatever that is), and then ultimately ignoring the code altogether.

What about dealing with the contents of __attribute__(( )) and [[attribute]] at semantic-time? So the parser just inserts a CAttributeDeclaration of sorts with the identifier name and optional arguments? Potentially then backends that understand these attributes can then do their own parsing and tag declarations at code-gen time too. ie: GDC and gnu:: attributes.

[PetarKirov]

@ibuclaw Initially, my goal was to map:

• [[deprecated("msg")]] (in addition to existing __attribute__((deprecated("msg"))) to D's deprecated("msg")
• [[noreturn]] (in addition to existing __attribute__((noreturn))) to D's noreturn type. However I later found that PR ImportC: add support for __attribute__((noreturn)) #12966 took a different route (just set a flag which is read only by the backend) and I followed, though I'd like to revisit this decision (though not in this PR).

Additionally, [[nodiscard]] seems quite useful to me (for the same reasons as D's @mustuse), so in the future I'd like us to wire it as well.

So for this reason, I found it natural (easier and more efficient) to do this in the parser. That said, I agree that its wasteful to throw this information after having spent the effort of parsing it. So inserting a CAttributeDeclaration node for at least the unknown attributes (still not convinced about the ones we do know about) seem like a good idea. I'll think about it more.

[PetarKirov]

@dkorpel I think I've managed to fix/address all of your comments, please confirm. I've extracted a separate PR for the duplicate deprecation message for enum members: #23283. We first need to merge that PR as this now depends on it.

[thewilsonator]

dependant PR merged, needs rebase.

[PetarKirov]

@thewilsonator rebased

[ibuclaw]

For the attributes that do have a direct mapping to D, it all gets set in the Scope during semantic time. See AttribDeclaration createNewScope. May need expanding to include C attributes not considered an attribute by D (nothrow? Haven't checked whether this is mapped in cparser)