| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If clazy is compiled with clang instead of gcc it might crash with:
==10637== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==10637== Access not within mapped region at address 0x8
==10637== at 0x19CDD8C: clang::ast_matchers::MatchFinder::MatchFinder(clang::ast_matchers::MatchFinder::MatchFinderOptions) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x9D75670: ClazyASTConsumer (Clazy.cpp:62)
==10637== by 0x9D75670: ClazyASTAction::CreateASTConsumer(clang::CompilerInstance&, llvm::StringRef) (Clazy.cpp:183)
==10637== by 0x9E29ED: clang::FrontendAction::CreateWrappedASTConsumer(clang::CompilerInstance&, llvm::StringRef) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x9E8FCA: clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x9AE3D5: clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0xA8C9FA: clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x5822C7: cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (in /usr/lib/llvm-7/bin/clang)
==10637== by 0x571ACC: main (in /usr/lib/llvm-7/bin/clang)
After debugging clazy and clang's code I couldn't find anything wrong with it.
Valgrind's output doesn't make much sense, and simply compiling the Clazy.cpp
translation unit with gcc instead of clang makes the crash go away and valgrind's output is clean.
I'm assuming debian's LLVM was built with gcc and building clazy with clang
will have some sort of incompatibility, or maybe it's simply a clang bug.
The downside of this workaround is that qcolor-literal check will be disabled.
Next step will be producing a minimal test case and reporting to LLVM.
BUG: 392223
CCMAIL: Woebbeking@kde.org
|
|
|
|
|
|
|
|
|
|
| |
This shuffles the code around in hope of avoiding what seems to be a
clang bug.
The backtrace and valgrind report don't make sense to me, and the crash
goes away if building clazy with gcc.
CCBUG: 392223
|
|
|
|
| |
(cherry-picked from 06edd15fdda9155b54366d3887a4fbf25cf1d911)
|
|
|
|
|
|
| |
Doesn't compile since it got noexcept
BUG: 391807
|
|
|
|
| |
BUG: 389360
|
|
|
|
| |
The operator path should only be executed on first iteration
|
|
|
|
|
| |
This was matching:
(should() ? container1 : container2).append("")
|
|
|
|
|
|
|
|
|
|
| |
Now it also fixes the second bug
Our previous fix wasn't being run because it was in the if (numImplemeted == 1),
so failed for the case where we have a user-dtor, user-copy-ctor and deleted-copy-assign.
Moving the check out of the if fixes it.
BUG: 388682
|
|
|
|
|
|
|
|
| |
It's safe, as it won't happen that one of the user-methods will do
something different from the compiler-generated-method, as one of
them can't be called.
BUG: 388677
|
|
|
|
|
|
|
|
|
|
| |
When you're using qDeleteAll(c.keys()) you should use qDeleteAll(c.keyBegin(), c.keyEnd())
The new messages are:
warning: qDeleteAll() is being used on an unnecessary temporary container created by QMap::values(), use qDeleteAll(mycontainer) instead [-Wclazy-qdeleteall]
warning: qDeleteAll() is being used on an unnecessary temporary container created by QMap::keys(), use qDeleteAll(mycontainer.keyBegin(), mycontainer.keyEnd()) instead [-Wclazy-qdeleteall]
CCMAIL: aacid@kde.org
|
|
|
|
|
| |
The parent() calls were not working since those nodes weren't
visited yet. Also fixes the unit-tests.
|
|
|
|
|
|
|
| |
Was returning false previously.
Fixes a false positive in range-loop.
CCMAIL: Ch.Ehrlicher@gmx.de
|
| |
|
|
|
|
|
|
|
|
|
| |
While QString::fromUtf8("ö") is equal to QString::fromUtf8("\xc3\xb6"),
QStringLiteral("ö") is not equal to QStringLiteral("\xc3\xb6") because the
escaped bytes won't be converted to utf-16 but instead used directly as is.
CCMAIL: faure@kde.org
CCMAIL: montel@kde.org
|
|
|
|
|
| |
No longer advises to pass 'this' as 3rd argument, because it might
make sense to pass another object there, should be the user to decide.
|
| |
|
|
|
|
|
|
|
| |
Qt::UniqueConnection only works with member functions, not functors
or lambdas.
CCMAIL: filipe.azevedo@kdab.com
|
|
|
|
|
|
| |
returning nullptr is enough
BUG: 386940
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the QObject has a signal with the same name of a Q_PRIVATE_SLOT
then the fixit would connect to the signal instead of the private
slot.
The fix is generic, if the user used the SLOT macro we simply
never rewrite to use a signal.
CCMAIL: dfaure@kdab.com
|
| |
|
|
|
|
| |
Differential Revision: https://phabricator.kde.org/D8377
|
|
|
|
|
| |
Needed in case Clazy is used as a plugin inside libclang. There, we
might have multiple threads accessing CheckManager concurrently.
|
|
|
|
| |
CCBUG: 385851
|
|
|
|
|
|
|
|
|
| |
Although clazy's built-in checks don't need this, some custom user
checks might
Not enabled by default as it causes a slight slowdown
BUG: 385851
|
|\ |
|
| |
| |
| |
| |
| |
| | |
These are fine to be called on a temporary, since they return a
reference to the object itself, which then must be stored or something
done with it due to Q_REQUIRED_RESULT
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
+ add space after this one.
It avoids line as :
error, invalid argIndex 3 3/compile/kde5/framework/kde/pim/kmail-account-wizard/src/cryptopage.cpp:226:9: warning: Pass 'this' as the 3rd connect parameter [-Wclazy-connect-3arg-lambda]
=> we have "3" without space so we can't copy path directly and we didn"t know when was the second "3"
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Q_ENUM() doesn't support that
|
| |
| |
| |
| | |
CCMAIL: jpnurmi@qt.io
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
Fixes fixit when the argument types have different const reference,
for example "const QString &" vs "QString", which are compatible.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
slots in a QThread derived classe is usually a code smell, because
they'll run in the thread where the QThread QObject lives, and not in
the thread itself.
Disabled by default, you'll have to explicitly enable it, and check
case by case if you have races.
|
| |
| |
| |
| |
| |
| |
| | |
Warns for:
- non-void const method marked as slot
- const method marked as signal
- connecting to a method which isn't marked as slot, is const and returns non-void
|
|\| |
|
| |
| |
| |
| |
| |
| | |
We check if the variable is used after the location where it was declared,
but it the expression begins with a macro, it was using the location of where
the macro was written, and where it was used.
|
| |
| |
| |
| | |
for performance reasons
|
|\| |
|
| |
| |
| |
| |
| | |
Too many false positives due to QString::fromLatin1() being
used instead tr().
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Summary:
When a qHash() function is defined for a enum class in a namespace, clazy wrongly prints the warning
'Move qHash(Foo::Bar) out of namespace Foo' because ContextUtils::namespaceForType() does not consider
enumerations. Therefore I changed QualType::getAsCXXRecorDecl() to QualType::getAsTagDec()
which returns the base class of RecordType and EnumType (and is the one which is passed to namespaceForDecl())
Type::getAsTagDecl() should be slightly faster since it avoids a dyna cast, don't know since when this function
is available though, at last it's in 4.0.0
version: clang version 4.0.1 (tags/RELEASE_401/final 305264)
Attn: there is also a change in main.cpp.expected since clang 4.0.0 prints qHash(IntFoo) instead the
expected qHash(NS::IntFoo) in the warning output ...
Test Plan:
- added enum class check to qhash-namespace unit test
- run test without modification which fails with the additional warning
+qhash-namespace/main.cpp:22:5: warning: Move qHash(NS::EnumClass) out of namespace NS [-Wclazy-qhash-namespace]
- apply my modification, re-run unit test, no additional warnings
Reviewers: smartins
Reviewed By: smartins
Subscribers: chehrlic
Differential Revision: https://phabricator.kde.org/D8010
|
| |
| |
| |
| |
| | |
This will only be done if -qt-developer is passed, as it's not
useful for user code
|
| |
| |
| |
| |
| |
| | |
When building Qt it will hounor Qt guidelines.
Used for performance reasons, so it doesn't run stuff that doesn't
apply to user code
|
| |
| |
| |
| | |
Checks that qHash() is declared inside the namespace of it's argument.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Warns when overriding a signal, which might make existing connects
not work, if done unintentionally.
Warns for:
- Overriding signal with non-signal
- Overriding non-signal with signal
- Overriding signal with signal
|
|\| |
|