[PATCH] D128619: [Clang] Implement P0848 (Conditionally Trivial Special Member Functions)

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.


================
Comment at: clang/lib/Frontend/InitPreprocessor.cpp:677
     //Builder.defineMacro("__cpp_aggregate_paren_init", "201902L");
-    Builder.defineMacro("__cpp_concepts", "201907L");
+    Builder.defineMacro("__cpp_concepts", "202002L");
     Builder.defineMacro("__cpp_conditional_explicit", "201806L");
----------------
aaron.ballman wrote:
> cor3ntin wrote:
> > royjacobson wrote:
> > > aaron.ballman wrote:
> > > > Does any of the not-yet-implemented bits (including from the DRs) impact the ability to use conditionally trivial special member functions? If so, we might want to be careful about aggressively bumping this value. (It's more palatable for us to come back and bump the value later than it is for us to claim we implement something fully when we know we don't -- the goal of the feature test macros is so that users don't have to resort to compiler version checks, which is what users have to use when they fall into that "not fully implemented" space.)
> > > I don't think they're very significant, and the benefits of enabling it seem large enough for me - for example, std::expected works with libstdc++ and passes their unit tests but is gated by this macro.
> > > 
> > > We still have a non-trivial amount of concept bugs to go over, but I support enabling this.
> > > 
> > I think it's better to be conservative, It's the lesser of two not great options.
> > I'm hoping we can get to fix the issues in the clang 16 cycle , but in the meantime we should not claim conformance if we are not, in fact, conforming.
> > We still have a non-trivial amount of concept bugs to go over, but I support enabling this.
> 
> I think we should specify the updated macro value only after we think concepts have no known major issues with them. (Unknown issues happen and there's not much we can do about them, this is more that we shouldn't specify that we conform to a particular feature test macro when we knowingly still don't have it right yet.)
Yeah, I don't think we can set this until we can at least compile a basic libstdc++ ranges use, which the deferred instantiation still holds up.  That would be my 'bare minimum' test for whether we can set that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128619/new/

https://reviews.llvm.org/D128619