MenuManager: modernize for loops

Can you check your const-correctness here? In at least a couple cases you've lost the iterator const-ness, and a quick glance through the loops makes it look like more of them could be const as well. We should silence those linter errors either by ensuring that the implicit sharing doesn't make copies, or if that's not a problem, by telling the linter to not display that error.

There are 2 for loops that were using ConstIterator, one of these :

QAction* MenuManager::findAction(const QList<QAction*>& acts, const QString& item) const
{
    for (QList<QAction*>::ConstIterator it = acts.begin(); it != acts.end(); ++it) {
        if ((*it)->data().toString() == item) {
            return *it;
        }
    }

    return nullptr; // no item with the user data found
}

However its the iterator that is const, not the action. So you cannot change to :

QAction* MenuManager::findAction(const QList<QAction*>& acts, const QString& item) const
{
    for (const auto* action : acts) {
        if (action->data().toString() == item) {
            return action;
        }
    }

    return nullptr; // no item with the user data found
}

Because then the return type is not correct anymore. Now it needs to be const QAction* which may break something downstream if those functions expect a non-const QAction*. Fixing const-correctness accross multiple files is outside the scope of this tiny PR that only want to simplify the syntax I came accross.

I do not understand the Lint warnings. However I only changed the syntax to newer type of for loop. So I do not see how it could create actual issues.

The linter warnings are not about the iterator variable but about the container where unnecessarily a deep copy could be created: c++11 range-loop might detach Qt container (QList) [-Wclazy-range-loop-detach]

To fix this warning the line
for (auto* item : _items) {
should be changed to
for (auto* item : std::as_const(_items)) {

I have changed to :
for (auto& item : _items) {

I think this syntax is preventing the deep copy issue and looks easier on the eye than the std::as_const.

Can you please let me know if this is ok or if it is better to use std::as_const?
Thanks

@wwmayer ?

Using the reference seems to work.