JonasToth added a comment.

Always the same with the templates ;) So uninstantiated templates should
just be ignored.

I think it would be better to have it in the ExprMutAnalyzer, because
that part can not decide on const-ness. Fixing it here would just
circumvent the problem but not fix it, would you agree?

Am 10.08.2018 um 22:12 schrieb Shuai Wang via Phabricator:

> shuaiwang added a comment.
> In, @JonasToth wrote:
>>> lCould you give a concrete example of this?
>> vi llvm/lib/Demangle/ItaniumDemangle.cpp +1762
>> /home/jonas/opt/llvm/lib/Demangle/ItaniumDemangle.cpp:1762:7: warning:
>>   variable 'num' of type 'char [FloatData<Float>::max_demangled_size]' can
>>   be declared 'const' [cppcoreguidelines-const-correctness]
>>         char num[FloatData<Float>::max_demangled_size] = {0};
>>        ^
>>   /home/jonas/opt/llvm/lib/Demangle/ItaniumDemangle.cpp:1763:7: warning:
>>   variable 'n' of type 'int' can be declared 'const'
>>   [cppcoreguidelines-const-correctness]
>>         int n = snprintf(num, sizeof(num), FloatData<Float>::spec, value);
>>        ^
> Looks like related to template.
>  the exact type of `num` depends on `Float`
>  and the `CallExpr` is not even resolved because we don't know the type of 
> the arguments yet (adl, overload resolution, etc.)
>  So the AST doesn't contain any array to pointer decay.
> I guess we should suppress the check in such cases.
> Repository:
>   rCTE Clang Tools Extra

  rCTE Clang Tools Extra

cfe-commits mailing list

Reply via email to