Bug 407321 - clazy-qvariant-template-instantiation: don't warn about type aliases
Summary: clazy-qvariant-template-instantiation: don't warn about type aliases
Status: REPORTED
Alias: None
Product: clazy
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Sergio Martins
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-08 07:27 UTC by Milian Wolff
Modified: 2019-05-09 19:11 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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