Since https://codereview.qt-project.org/c/qt/qtbase/+/303079 <https://codereview.qt-project.org/c/qt/qtbase/+/303079> landed, there are a lot of deprecation warnings. I’ve been using clazy to fix them, as in https://codereview.qt-project.org/c/qt/qtbase/+/303079 <https://codereview.qt-project.org/c/qt/qtbase/+/303079> and https://codereview.qt-project.org/c/qt/qtsvg/+/303448 <https://codereview.qt-project.org/c/qt/qtsvg/+/303448>. To make that possible, I added a qevent-accessors check to it, which is currently on the tip of my fork: https://github.com/ec1oud/clazy <https://github.com/ec1oud/clazy>. I plan to try to upstream that change. But there might end up being more things that need to be done with QEvent accessors, so maybe it’s a little early to finalize what changes this particular qevent-accessors check will suggest.
A clazy check just generates more warnings in general; but it can also include replacement text (a source code change). Most pre-existing checks do not yet include fixes, but IMO it’s much more useful if it does include a “fixit”, because that can be automatically applied. You can see in my patch how I did that. Discovering llvm APIs isn’t so straightforward for me yet, but at least I figured out how to do that sort of renaming in a way that doesn’t generate false positives. As explained in the commit messages, if you run cmake you can specify -DCMAKE_CXX_COMPILER=/usr/bin/clazy ; if you run qmake you can configure with a clang platform, -no-pch QMAKE_CXX=clazy. At least using it as a compiler wrapper is one way; there’s also clazy-standalone, but I was not having as much luck with that so far. You want your build to include tests and examples too, so that they get checked (and fixed, to the extent possible). Don’t use icecream or ccache, because it will bypass clazy. The clazy-suggested fixes will generate a bunch of *.clazy.yaml files in the source tree (even if you are doing a shadow build, which I recommend, the yaml files go to the source directories). Then you can go to the top of the module source and clang-apply-replacements . to apply those to the source files; git add -p to verify that each change is really a good one (and appropriate to be grouped in one patch); generate a commit and push it. (The yaml files specify changes using byte offset, length, and replacement text, so that’s ephemeral obviously.) I already generated patches for several more Qt 6 modules to take care of those event accessor deprecations so far. But maybe it’s a good practice to do more of this, rather than applying API changes by hand. When we add features to clazy, we will make it easier for users to port their code from Qt 5 to 6, too. We could add something to the docs about that. BTW one of its limitations seems to be that clang and clazy have to be in the same directory, so that's why I had to configure clazy with cmake -DCMAKE_INSTALL_PREFIX=/usr and sudo make install. And so far I have not succeeded in using it on macOS, which I think is because of that limitation. It would be nice if that gets fixed somehow.
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
