rjmccall added a comment. This seems like the right idea to me, yeah. It doesn't look like the patch handles `volatile _Atomic` correctly, though.
I know we do a lot of candidate prefiltering, and that that can be difficult because of uesr-defined conversions. How do those things interact with qualifiers? Like, I notice the existing code is adding both `(T &, T)` and `(volatile T &, T)` when the LHS is `volatile`; is there a reason that's necessary? Because we can't actually convert the LHS to remove those qualifiers, and adding combinatoric candidates could get very expensive if we start doing it for arbitrary extended qualifiers, which it feels like we ought to. (You could certainly have e.g. a `volatile _Atomic __myaddrspace` l-value.) If this is only necessary when the LHS has a user-defined conversion, then maybe we could at least not do it in the normal case just because the RHS is an overloaded type. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125349/new/ https://reviews.llvm.org/D125349 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
