dmpolukhin wrote: Agreed on a warning rather than error-by-default: GCC accepts this silently, and a project built only with Clang is self-consistent, so an error would break working builds; `-Werror` is there for those who want it.
On location, the real code I found is the opposite of "later declaration is wrong". Where the system header declares the tagged namespace first, user reopenings are bare or repeat the same tag — NVIDIA CCCL [`__fwd/string.h`](https://github.com/NVIDIA/cccl/blob/48414ba7ec5a2f10fc348961e84540f974162b4d/libcudacxx/include/cuda/std/__fwd/string.h#L34-L44) (ships with the CUDA Toolkit), folly [`Traits.h`](https://github.com/facebook/folly/blob/44f373be76a8c0c5403fb59a877a42f969116461/folly/Traits.h#L578-L586) until 2019, range-v3 [`meta.hpp`](https://github.com/ericniebler/range-v3/blob/108f93c279c8f9cec175dac361084983d0176e99/include/meta/meta.hpp#L3808-L3811)). None of them adds a tag, so with the narrowed rule nothing fires. What does fire is the reverse order: a user forward declaration of `std::__cxx11` / `std::filesystem::__cxx11` before `<string>` / `<filesystem>`. There the declaration adding the tag is libstdc++'s: a warning at that location is silenced as a system-header diagnostic, and the fix belongs to the first declaration. I found no real case of a user adding a *different* tag to a system-provided namespace. So I'd emit the warning at whichever of the two declarations is not in a system header (the tag-adding one when both are user code), with a note at the other. One more thing while you're updating: `-Wabi-tag` already exists in GCC with an unrelated meaning ("inherits the X ABI tag"), so shared build flags would toggle this warning by accident; a different group name (e.g. `-Wabi-tag-redeclaration`) avoids that. https://github.com/llvm/llvm-project/pull/221039 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
