Bug 423780 - clazy-fully-qualified-moc-types not detecting missing namespace
Summary: clazy-fully-qualified-moc-types not detecting missing namespace
Status: REOPENED
Alias: None
Product: clazy
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-02 04:24 UTC by Christian Gagneraud
Modified: 2022-09-14 14:01 UTC (History)
3 users (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 Christian Gagneraud 2020-07-02 04:24:42 UTC
SUMMARY

Given an enum E in a class C in a namespace N, clazy reports an error when the enum is used fully-unqualified (E value), but doesn't report an error if used partially-qualified (C:E value).
The only valid usage should be "N:C:E value"

Or the documentation is not accurate, here is the given example:
namespace MyNameSpace {

    struct MyType { (...) };

    class MyObject : public QObject
    {
        Q_OBJECT
        Q_PROPERTY(MyGadget myprop READ myprop); // Wrong, needs namespace
    Q_SIGNALS:
        void mySignal(MyType); // Wrong
        void mySignal(MyNameSpace::MyType); // OK
    };
}


STEPS TO REPRODUCE
run clazy on:
namespace N { 
 class C: QObject 
 { 
  Enum E {}; 
 signals: 
  void function(C:E value) {} 
 }
}

OBSERVED RESULT
No error reported

EXPECTED RESULT
"signal arguments need to be fully-qualified" is emitted


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

ADDITIONAL INFORMATION

Stock clazy on Ubuntu 18.04, based on LLVM-6.0.0
Comment 1 Evgeniy A. Dushistov 2021-04-15 15:13:51 UTC
I get the same problem.
Comment 2 Evgeniy A. Dushistov 2021-04-15 16:39:56 UTC
I made some experiments, and looks like clazy should be run against output of moc, not against header by it self:

```
// boo.h
#pragma once

#include <QObject>

namespace MyNameSpace {

    struct MyGadget {
        Q_GADGET
    };

    class MyObject : public QObject
    {   
        Q_OBJECT
        Q_PROPERTY(MyGadget myprop READ myprop CONSTANT); // Wrong, needs namespace
    public:
        MyGadget myprop() const;
    };
}
```

clazy-standalone --extra-arg="-I/usr/lib/clang/11.1.0/include" --checks=level0,level1,level2   -p ./build/compile_commands.json boo.h

reports nothing,
but

```
$ clazy-standalone --extra-arg="-I/usr/lib/clang/11.1.0/include" --checks=level0,level1,level2   -p ./build/compile_commands.json build/moc_boo.cpp
In file included from moc_boo.cpp:10:
build/../boo.h:11:5: warning: Q_PROPERTY of type MyGadget should use full qualification (MyNameSpace::MyGadget) [-Wclazy-fully-qualified-moc-types]
    class MyObject : public QObject
    ^
1 warning generated.
```
Comment 3 Sergio Martins 2021-05-15 09:54:39 UTC
Git commit b183b3312edd1781788cc598d5a89f344d7c8d7f by Sergio Martins.
Committed on 15/05/2021 at 09:48.
Pushed by smartins into branch 'master'.

fully-qualified-moc-types: Explain why Q_PROPERTY warns on moc output only

Q_PROPERTY is a macro that doesn't expand to anything. It won't appear in
the AST. The properties only appear in the moc output.

It will warn that your Q_PROPERTY needs to be fully qualified when you do
a full build with clazy as the compiler, but probably not in QtCreator's
inline warnings.

Working at the Lexer level without a code model would not
only be hardwork but would be flaky with many corner cases and false-positives.

M  +3    -0    docs/checks/README-fully-qualified-moc-types.md

https://invent.kde.org/sdk/clazy/commit/b183b3312edd1781788cc598d5a89f344d7c8d7f
Comment 4 Sze Howe Koh 2022-09-14 14:01:58 UTC
The patched documentation addresses the missing warning in Q_PROPERTY(). What about the test case in the original post?

namespace N { 
 class C: QObject 
 { 
  enum E {}; 
 signals: 
  void function(C::E value) {} // Wrong, needs namespace
 };
}

See also https://bugreports.qt.io/browse/QTCREATORBUG-28120