================
@@ -141,3 +141,15 @@ namespace r360308_regression {
return a == b;
}
}
+
+namespace GH95598 {
+template<typename _Tp, bool _IsPtr = __is_pointer(_Tp)>
+struct __is_pointer {};
+// expected-warning@-1 {{keyword '__is_pointer' will be made available as an
identifier for the remainder of the translation unit}}
----------------
AaronBallman wrote:
Thanks for the historical information @zygoloid!
> I don't think we should be extending this hack further. I've suggested on the
> libstdc++ bug report that this be fixed in libstdc++ instead, by stopping
> using our keywords as their type names. Maybe one day we can then remove it
> entirely.
I tend to agree; if we can avoid continuing to extend this hack, I think we
should. That said, I'd be curious whether deprecation is highly disruptive or
not; my intuition is that we'd struggle with this one because people tend to
use boost (and certainly libstdc++) as system headers, and we suppress
diagnostics by default in system headers. So I'd expect this deprecation to
take a *long* while before we could remove the hacks due to the long tail of
not wanting to break system headers.
The ctor situation would be annoying, but I think the ctor and dtor are the
only places we'd have to put in a special hack for "got a keyword where we
expected an identifier", so perhaps the blast radius is sufficiently limited
for that to be a reasonable approach?
https://github.com/llvm/llvm-project/pull/95969
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
