[clang] [C23] Implement WG14 N3037 (PR #132939)

uecker wrote: > > Once that is settled, then go back to work on redeclaration/definition > support. Possibly it'd be good to pause and ask the standards body to clarify > how it's supposed to work first. While I think my proposed semantics above > make sense, the standard doesn't actually _sp

[clang] [C23] Implement WG14 N3037 (PR #132939)

@@ -450,6 +453,116 @@ class StmtComparer { }; } // namespace +static bool IsStructurallyEquivalent(StructuralEquivalenceContext &Context, + const Attr *Attr1, const Attr *Attr2) { + // Two attributes are structurally equivalent if they are

[clang] [C23] Implement WG14 N3037 (PR #132939)

uecker wrote: > Curiously, GCC doesn't merge the standard attributes either, it seems to do > last-one-wins: https://godbolt.org/z/j3W7ej5Kq I filed a bug for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119526 https://github.com/llvm/llvm-project/pull/132939

[clang] [C23] Implement WG14 N3037 (PR #132939)

uecker wrote: > I now see there's two different parts of the problem to worry about: > > First case: A redeclaration in a _different_ scope. This always defines a new > distinct type. This was valid before C23, and is still valid regardless of > whether the type is compatible. (In contrast wit

[clang] [C23] Implement WG14 N3037 (PR #132939)

uecker wrote: Another comment about attributes: Attributes should not generally affect type compatibility (in general, but also relevant for this feature) for two reasons: 1. Standard attributes are ignorable, and this would then break. 2. Compatibility affects aliasing, one one certainly does

[clang] [C23] Implement WG14 N3037 (PR #132939)

@@ -450,6 +453,116 @@ class StmtComparer { }; } // namespace +static bool IsStructurallyEquivalent(StructuralEquivalenceContext &Context, + const Attr *Attr1, const Attr *Attr2) { + // Two attributes are structurally equivalent if they are

[clang] [C23] Implement WG14 N3037 (PR #132939)

@@ -450,6 +453,116 @@ class StmtComparer { }; } // namespace +static bool IsStructurallyEquivalent(StructuralEquivalenceContext &Context, + const Attr *Attr1, const Attr *Attr2) { + // Two attributes are structurally equivalent if they are

[clang] [C23] Implement WG14 N3037 (PR #132939)

uecker wrote: BTW: I did not push for this feature to be exposed in earlier language modes because GCC will ship with GNU C23 by default with GCC 15. GCC 15 already saw distribution-wide testing in Redhat and Debian and from this experience I do not expect any problems related to this featur

[clang] [C23] Implement WG14 N3037 (PR #132939)

uecker wrote: > It seems to me that we could simplify the implementation by being a bit more > literal in the interpretation of the requirements: look only at the type, > alignment, name, and bitfield-width of members. Just don't bother checking > other stuff > > I'd hope it can look more lik

[clang] Diagnose potential size confusion with VLA params (PR #129772)

@@ -0,0 +1,68 @@ +// RUN: %clang_cc1 %s -std=c23 -verify=expected,c -fsyntax-only +// RUN: %clang_cc1 %s -std=c23 -verify=good -fsyntax-only -Wno-vla +// RUN: %clang_cc1 -x c++ %s -verify -fsyntax-only +// RUN: %clang_cc1 -DCARET -fsyntax-only -std=c23 -fno-diagnostics-show-line-

[clang] Diagnose potential size confusion with VLA params (PR #129772)

uecker wrote: And a final comment. While the main motivating use case for you may be VLAs in parameter declarations (although as heavy user of those, I never felt the need for such a warning), it would seem the warning would be relevant in cases where the arrays are not actually VLAs. In ge