ldionne added a comment. In D135341#4111884 <https://reviews.llvm.org/D135341#4111884>, @cjdb wrote:
> In D135341#4111673 <https://reviews.llvm.org/D135341#4111673>, @ldionne wrote: > >> I've been looking at implementing `reference_constructs_from_temporary` & >> friends and this would be sweet to have. Is this blocked on something >> specific? > > This trait should be ready to go, pending an LGTM. > `__reference_converts_from_temporary` is a different story, and someone else > might need to do this one if you need it in a timely fashion (but I'll be > happy to review it). Sounds good! This naively looks good to me, but it would be nice if a Clang regular could take a look! ================ Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:397 +def err_reserved_identifier_for_future_use : Error< + "%0 is a compiler-reserved identifier for a future feature">; } ---------------- cjdb wrote: > ldionne wrote: > > cjdb wrote: > > > erichkeane wrote: > > > > I don't think we should diagnose this for individual identifiers, I > > > > don't think this adds much value, and the identifier is already > > > > reserved for implementation use. This implies we are going to diagnose > > > > ALL future reserved things, which we have no intention of doing. > > > The motivation for this error is to ensure that standard library > > > implementations don't take this name (`__remove_cvref` and > > > `__is_null_pointer` had to get names that weren't a 1:1 mapping to their > > > library counterparts as a result). > > Oh, just ask and we can rename ours! What do you want us to rename? > Much appreciated! I think `__remove_cvref` had a libc++ conflict and > `__is_null_pointer` had a libstdc++ conflict, so it's not specific to one > library. I figured that it would be easier for backwards-compatibility > reasons to just rename them to something slightly more awkward, so that > previous versions of the stdlib don't spontaneously break for more recent > compilers. This is more of an issue when you're dealing with package managers > like apt, where some things depend on libc++-v$OLD, but there aren't any > restrictions on Clang's version (for example, I use nightly Clang on Ubuntu, > but apt notes that the Discord app has an older libc++ dependency). > > After having let this sit for a few months, I don't really have strong > opinions on reserving `__std_trait` anymore, so I'll touch this up in the > morning. I just checked and I think we define `__remove_cvref_t`, but not `__remove_cvref` (that probably changed in the last year). In the future, don't hesitate to ping us if we are using a name that Clang would like to use, we should almost always be able to quickly get out of your way! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135341/new/ https://reviews.llvm.org/D135341 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
