aaron.ballman added a comment.

In D107292#2943101 <https://reviews.llvm.org/D107292#2943101>, @cjdb wrote:

> In D107292#2939521 <https://reviews.llvm.org/D107292#2939521>, @aaron.ballman 
> wrote:
>
>> One question I have about both declarations and expressions are whether we 
>> have an appetite to diagnose overloaded operators or not. Personally, I 
>> think it'd be reasonable to diagnose something like `foo->operator 
>> bitand();` or `operator not_eq(A, B);` as expressions, but not reasonable to 
>> diagnose the declaration of the overloaded operators using alternative 
>> tokens.
>
> I agree that `bool operator and(T, T);` shouldn't be diagnosed on (and this 
> patch's clang-tidy sibling will one day also diagnose that, but it's way off).
>
> I think that `foo->operator bitand()` and `operator not_eq(expr1, expr2)` 
> should only diagnose if `foo->operator&()` and `operator!=(expr1, expr2)` are 
> diagnosed, //and// I think that should be a separate warning (I'm not saying 
> that's a good or bad thing to do yet: let me sleep on that). I might be 
> misunderstanding your intention though.

The situation I was thinking of was where the the declaration is for an 
`operator&()` function but the expression is calling `operator bitand()` (or 
vice versa), but 1) I don't feel strongly it needs to be diagnosed, mostly just 
exploring the shape of the diagnostic, and 2) I'd be fine if it was handled 
under a separate flag at some later date.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107292

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to