D14288: Initial version of Clazy analyzer plugin

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Issues seen while testing:
  
  Project config page:
  
  - Initial page shows a commandline which does not reflect the state of the options (e.g. showing "-qt4-compat" while the respective "Qt4-compatible" button is off.
  
  - Selecting just the levels makes it look as if checks from the lower levels would not be run.
  
  -> with current UI if selecting a higher level then all sublevels should be autoselected (besides those already activated and keeping any disabled checks). Perhaps also needs another UI which reflects the clazy's level concept more, perhaps by still having the tree but with radio buttons for the levels and two "explicit include" "explicit exclude" buttons per checks to override the settings by level
  
  - It is possible to unselect all levels
  
  -> if user unselects all levels, UI settings should jump back to autoenable level 1, given this is also the default with clazy
  
  - Links to check documentation go out to  internet, despite documentation locally existing
  
  -> local installed docs should be shown, matching used flags, perhaps in optional view to the right of the list (will come up with a patch for that using KParts) or trying to reuse the custom markdown parser as used for the checker tooltips and/or showing the docs as tooltips as well. Are the doc pages actually that different from the output of "clazy --explain foo"?
  
  Running the analyzer:
  
  - trying to run on a program without compile_commands.json existing just gets a warning that the file is missing
  
  -> Plugin should check for the file itself and  warn if not found. That warning then should include some hint how to ensure that file exists (something similar to the text clazy has itself: "See https://clang.llvm.org/docs/JSONCompilationDatabase.html for how to generate the compile_commands.json file. Basically it's generated by passing -DCMAKE_EXPORT_COMPILE_COMMANDS to CMake, or using Bear to intercept compiler commands, or, if you're using qbs: qbs generate --generator clangdb" But adapted to kdevelop and talking about cmake config page etc)
  Perfect, but as some future improvement, would be to have a button to add this automatically. Needs possibly bigger kdev infrastructure work to support that :)
  
  - running with clazy-standalone binary not being located in the same folder as the clang binary, one runs into the issue as documented on the main clazy docs
  
  -> Plugin should check for that case and report a respective warning (again following the text from clazy's docs)
  Otherwise the developer testing the plugin looks at the following and thinks that stuff is just broken ;)
  
    > make -j1 -f /home/koder/projects/dupdup/build/kdevclazy.makefile
    Clazy check started  for /home/koder/projects/dupdup/src/main.cpp
    In file included from /home/koder/projects/dupdup/src/main.cpp:1:
    In file included from /home/koder/projects/dupdup/src/dupdup.h:4:
    In file included from /usr/include/qt5/QtWidgets/QMainWindow:1:
    In file included from /usr/include/qt5/QtWidgets/qmainwindow.h:43:
    In file included from /usr/include/qt5/QtWidgets/qtwidgetsglobal.h:43:
    In file included from /usr/include/qt5/QtGui/qtguiglobal.h:43:
    In file included from /usr/include/qt5/QtCore/qglobal.h:46:
    /usr/bin/../lib64/gcc/x86_64-suse-linux/8/../../../../include/c++/8/cstddef:50:10: fatal error: 'stddef.h' file not found
    #include <stddef.h>
             ^~~~~~~~~~
    1 error generated.
    Error while processing /home/koder/projects/dupdup/src/main.cpp.
    make: *** [/home/koder/projects/dupdup/build/kdevclazy.makefile:7: /home/koder/projects/dupdup/src/main.cpp] Error 1
    Elapsed time: 1.579 s.
    *** Failure: Exit code 2 ***
  
  Otherwise works here as intended :) Good work! This should make clazy more accessible and known to people.
  
  Quick dump of feature wishes for the future by first usage experience:
  
  - in the project config page have a search bar on the level/checks treelist to help finding a certain check by name
  - being able to see which checks provide a fixit (seems that needs support by clazy query cmdline API)
  - select per check whether to apply a fixit (depends on clazy support as well)
  - supporting configuration sets, so one could reuse a certain check/fixit config across different projects (e.g. to ensure org standards or to do some)

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D14288

To: antonanikin, #kdevelop
Cc: kossebau, kdevelop-devel, antismap, iodelay, vbspam, njensen, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180729/3d65d2db/attachment.html>