JonasToth added a comment.
> I'm not sure I understand what you're trying to break in the check. If you're
> thinking of whether the code trips up on the lexical issues, I'm pretty sure
> that won't apply here. Once the const-ness is hidden behind a template, the
> check doesn't try to fix it; so, lexical issues don't come into play. It
> boils down to the whether the matcher for const-ness is implemented
> correctly. But, I did add a new test based on this:
> `template <typename T> const T p32(T t) { return t; }`
> which *is* detected and fixed. Let me know, though, if you want something
> more elaborate. Also, see below, where I *did* find a bug in a related kind
> of type definition.
Yup, just tried to hammer with man possible `const`-applications.
> I've modified the code that finds the const token to fix this bug. In the
> process, I simplified it and (I think) found a more general solution to the
> problem. I also noticed that this same bug exists in the
> AvoidConstParamsInDecls check, so I plan to send a follow up change that
> fixes that check by having it use the newly introduced
> `getConstQualifyingToken` function.
Perfect!
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D53025
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
