================
@@ -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}}
----------------
zygoloid wrote:
I think we've incrementally ended up in a bad place. Here's my memory of what
happened:
Originally, the idea was: we provide builtins such as `__is_pointer` for use by
the standard library. But for a bunch of those, libstdc++ provides a type with
the same name that works it out for itself. OK, we can work around that: if we
see a declaration with that name, then the standard library isn't using our
builtin, so we treat it as a non-keyword so that libstdc++ doesn't break.
But then it turns out that boost uses these things as keywords directly, rather
than using the standard library functionality. To keep both that and libstdc++
working at the same time, we treat the keyword followed by an open paren as
having the builtin meaning even when the keyword has been reverted to being a
non-keyword.
And now we're noticing that we also need special behavior in other parts of the
parser to treat the keyword followed by an open paren as a special case.
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.
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
