Abandoning in favor of cjdb's more active contributions.

Previous standards didn't disallow this AFAIK.

In D78938#2450915, @nlopes wrote:

Thanks @lebedev.ri for the pointer!
I started working on exactly the same thing as I was trying to link a C++20 project with LLVM.
@BRevzin is there anything missing in this patch? Do you have commit access or do you need help to land this?

@BRevzin, you should a) mention the u8/const char* issue in the description too, and also what compiler you used to build this with. I fully expect at this stage that there are some C++20 compilers that might have slightly different interpretations of things which this won't resolve, so knowing which one this is intended to work with could help with historical research.

In D78938#2258557, @jhenderson wrote:

Not that I have anything particularly against this, but won't this likely rot fairly rapidly? It's not like LLVM is even on C++17 let alone C++20 yet, so trying to make it work like the latter when it's just going to break again seems a bit like wasted effort to me.

Updating this review with some additional changes that need to be made since I last touched it, and some of the previous changes had inadvertently broken the C++14 build so fixing those as well.

• Explaining the cryptic parentheses.

• Backing out changes that aren't strictly comparison-related.

I hadn't build the tests before, updated with a few more changes. Some of the tests require u8 literals, whose type changes in C++20. I had no idea what to do with that, so I just #ifdef-ed out those tests with the appropriate feature test macro.

• Adding missing return.

• A few more changes from tests.

In D78938#2007037, @dblaikie wrote:

(peanut gallery: I'd consider, while you're touching these all anyway, changing them all to non-member (friended where required) as I believe that's best practice - allows equal implicit conversions on either side, for instance (even if some types have no implicit conversions - it at least provides a nice consistency/examples that people are likely to copy from))

Trying this again.

In D78938#2006758, @hubert.reinterpretcast wrote:

In D78938#2006715, @BRevzin wrote:

Wtf, where'd my other changes go?

I've hit this before, use arc diff --update D78938 <base_branch>.

Wtf, where'd my other changes go?

More idiomatic comparison implementation.

This review changed just the one type, I went ahead and fixed the rest of the clang build in a bigger review.

In D74186#1906326, @EricWF wrote:

I would rather see a patch that only removes the removed interfaces, and doesn't do all the additional cleanup you've done.

Splitting the diff to JUST remove weak/strong_equality.

In D41740#968134, @JonasToth wrote:

Could you please add a test case with a template that reduces the type to int8 or uint8?

Updates based on review comments - and rebased off of latest so as to get the ReleaseNotes right. Added options so that the user can provide the list of stream types and int typedef types, as desired, defaulting to just basic_ostream and int8_t/uint8_t.

So admittedly, I don't have any experience in clang-tidy. This check is intended to catch what is to us a really annoying source of error (and I'm probably not the only one?). I suspect there are far better ways of writing this check than the one that I pretty much guess-and-checked my way into.