Bug 407321

Summary: clazy-qvariant-template-instantiation: don't warn about type aliases
Product: [Developer tools] clazy Reporter: Milian Wolff <mail>
Component: generalAssignee: Sergio Martins <smartins>
Status: REPORTED ---    
Severity: normal CC: smartins
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Milian Wolff 2019-05-08 07:27:25 UTC 
SUMMARY
I want to suggest that QVariant::value shouldn't warn when we pass a type alias. The type alias may be platform dependent, and thus it's not always clear that e.g. QVariant::value<quintptr> should be replaced by toUnsigned long long. Also, it makes the code harder to understand I believe.

Unrelated: couldn't we fix this whole issue upstream by explicitly specializing value<> for the builtin types and forwarding those to the toX functions?

STEPS TO REPRODUCE
line 250: settings.conversion.color = value.value<QRgb>();
=> Use QVariant::toUnsigned int() instead of QVariant::value<unsigned int>()
line 176: return reinterpret_cast<QDockWidget *>(tabBar->tabData(tabIndex).value<quintptr>());
=> Use QVariant::toUnsigned long long() instead of QVariant::value<unsigned long long>()

OBSERVED RESULT
warnings for typealiases

EXPECTED RESULT
no warnings

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Sergio Martins 2019-05-09 16:53:24 UTC 
The AST for v.value<int>() is the same as v.value<qint32>() :/

getting the used typedef usually works, but in this case (with templates) I'm not seeing how. I guess because the compiler instantiates the value<int> template directly, discarding the original typedef info.

Will have to parse what's inside < and > manually
Comment 2 Sergio Martins 2019-05-09 19:11:15 UTC 
Git commit 52c35819162bd23b3b4e406784fa5cbc17cedfcc by Sergio Martins.
Committed on 09/05/2019 at 19:10.
Pushed by smartins into branch 'master'.

qvariant-template-instantiation: Move out of level 0, since it has false-positives

This check has really been noise since its creation. The rate of false-positives
don't justify the insignificant compilation performance gains. Moved to manual level now.

Currently it has a bug, which doesn't seem possible to solve,
as the instantiated template doesn't carry over the information about the qint32 typedef.
And the CallExpr doesn't have any template related getters.

Also removed this check from the "performance" category in checks.json, since
this category is for runtime performance.

M  +1    -1    CheckSources.cmake
M  +1    -1    README.md
M  +1    -2    checks.json
M  +6    -1    docs/checks/README-qvariant-template-instantiation.md
M  +1    -1    readmes.cmake
M  +2    -2    src/Checks.h
R  +0    -0    src/checks/manuallevel/qvariant-template-instantiation.cpp [from: src/checks/level0/qvariant-template-instantiation.cpp - 100% similarity]
R  +0    -0    src/checks/manuallevel/qvariant-template-instantiation.h [from: src/checks/level0/qvariant-template-instantiation.h - 100% similarity]

https://commits.kde.org/clazy/52c35819162bd23b3b4e406784fa5cbc17cedfcc