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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
