erichkeane wrote: > > I don't think this is a good idea, warning on EVERY use of this is > > incorrect in system headers. IT is going to result in a ton of > > we-want-to-be-suppressed-positives > > Thanks @erichkeane. I think I fundamentally disagree with this. The entire > intention of this attribute is to flag such a thing -- it's no different from > calling `std::invoke(foo, x)` and expecting to get a diagnostic on _every_ > invocation when the function is `void foo(int x, int y)`, especially when you > consider that these are basically simulating named-parameters. Do you have a > plausible use case in mind that makes you believe people would actually want > to suppress the warning in system headers?
Hmm... I just spent a while looking at the attribute more and changed how I was thinking about this problem, and I'm less confident in my above statement. SINCE this is competely opt-in we could presumably document this better to mean "we mean this even if it is in the nitty-gritty of the standard library". Typically these sorts of attributes don't really mean that/are intended for use in violations by the 'users' code. Of course, `construct-at` and `invoke`/etc all make this somewhat more complicated of a differentiation. My biggest 'plausible' concern is cases where the system header needs to make irrelevant/unused temporaries for the purposes of various operations along the way, which still DO the right thing but are wrong along the way. BUT I also wonder how much sympathy I have for those cases when the author of the type has opted into this. https://github.com/llvm/llvm-project/pull/141133 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
