[KIO] Make it compile without foreach (Step 1)
ClosedPublic

Authored by mlaurent on Apr 12 2019, 11:47 AM.

Details

Summary

Port a lot of foreach/FOREACH (still 220 items)
It will be deprecated in qt6.

NO_CHANGELOG

Test Plan

autotest ok

Diff Detail

Repository
R241 KIO
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
mlaurent created this revision.Apr 12 2019, 11:47 AM
Restricted Application added a project: Frameworks. · View Herald TranscriptApr 12 2019, 11:47 AM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
mlaurent requested review of this revision.Apr 12 2019, 11:47 AM
krop added a subscriber: krop.EditedApr 12 2019, 12:57 PM

Please fix the title

what is the problem with title ?

krop added a comment.Apr 12 2019, 1:17 PM

what is the problem with title ?

"Make to compile without foreach"

it's missing words or some have to be changed.
The summary also lacks explanations *why* this change is needed (like almost *all* the commits in the pim repositories)

we're not using SVN anymore where a commit had to be pushed before preparing the next one, there's time to explain things.

mlaurent retitled this revision from [KIO] Make to compile without foreach (Step 1) to [KIO] Make it compile without foreach (Step 1).Apr 12 2019, 1:23 PM
mlaurent edited the summary of this revision. (Show Details)
dfaure requested changes to this revision.Apr 13 2019, 10:50 AM

cgiboudeaux: the Qt documentation says that foreach is deprecated, what do you suggest Laurent should add to the commit log? Just "it's deprecated", a copy/paste of the Qt docu, or https://www.kdab.com/goodbye-q_foreach/ ?

autotests/globaltest.cpp
110

qAsConst? I guess QFETCH doesn't make the variables const.

src/widgets/kdirmodel.cpp
263

qAsConst

This revision now requires changes to proceed.Apr 13 2019, 10:50 AM
krop added a comment.Apr 13 2019, 10:59 AM

cgiboudeaux: the Qt documentation says that foreach is deprecated, what do you suggest Laurent should add to the commit log? Just "it's deprecated", a copy/paste of the Qt docu, or https://www.kdab.com/goodbye-q_foreach/ ?

"It will be deprecated in Qt6" tells packagers why this commit is done.
In a perfect world, developers would write changelog files with changes worth mentioning when packagers prepare the updates.
As this is not close to happen, we extract git logs and spend an insane amount of time cleaning meaningless commit messages for *each* released tarball (and specially the pim ones) and we repeat that for *every* release.

mlaurent added inline comments.Apr 13 2019, 12:09 PM
autotests/globaltest.cpp
110

indeed.

src/widgets/kdirmodel.cpp
263

Ah yep I thought that it was the args from method.
I will fix it soon

Yep, but extracting changelogs from commit logs can be mostly automated, including filtering out many commits with the same first line.
It's what I do in git@git.kde.org:sysadmin/release-tools branch frameworks/5.0 file parse_changelogs.pl.

But yeah, if people could add NO_CHANGELOG somewhere in the commit log it would make this easier. Laurent, can you do that for mechanical commits such as this one?

mlaurent edited the summary of this revision. (Show Details)Apr 13 2019, 1:04 PM
mlaurent updated this revision to Diff 56136.Apr 13 2019, 1:07 PM

Add missing qAsConst

"But yeah, if people could add NO_CHANGELOG somewhere in the commit log it would make this easier. Laurent, can you do that for mechanical commits such as this one?"

no problem for adding [NO_CHANGELOG] in commit message

dfaure accepted this revision.Apr 13 2019, 1:47 PM

FYI NO_CHANGELOG doesn't have to be in the first line (which would make noise in phab review titles for new requests, etc). It can be a line of its own, for example towards the end of the commit log.

Thanks!

This revision is now accepted and ready to land.Apr 13 2019, 1:47 PM
mlaurent edited the summary of this revision. (Show Details)Apr 13 2019, 4:27 PM
This revision was automatically updated to reflect the committed changes.
aacid added a subscriber: aacid.Apr 13 2019, 9:12 PM

FYI NO_CHANGELOG doesn't have to be in the first line (which would make noise in phab review titles for new requests, etc). It can be a line of its own, for example towards the end of the commit log.

Thanks!

Isn't that what GIT_SILENT is for? Do we really need another keyword?

GIT_SILENT is "trivial, don't look at the commit" -- at least it used to be. Not really applicable to commits such as this one....

hmmmm, ok, i don't know why we wouldn't want things like this to now show in the autogenerated changelog, but ok, your call :)

I view the KF5 changelog as the list of things that can be useful to the users of the frameworks (i.e. application developers).
When we add API, fix a bug, or change dependencies, that's useful for them to know.
When we repair a unittest, fix typos in comments, port away from deprecated methods and so on, I don't see how that is useful for the application developers to know. To me it would just be noise in the changelog, it doesn't affect them.
Sure, in the long run it means we're maintaining the stuff and making sure it will still work with future versions of Qt, but they'll get notified of that when the time comes anyway.

cfeck added a subscriber: cfeck.Apr 14 2019, 2:20 PM

Do we understand all possible regressions that this can cause? If yes, where are they documented so that we can verify? See bug 406426.

Yes, the pitfalls are well known.

  1. don't modify the container being iterated upon (from inside the loop)
  2. don't use qAsConst on temporaries

and for performance reasons, "don't use range-for over a non-const container", but that's of course not as bad as 1) and 2) which lead to crashes.

https://www.kdab.com/goodbye-q_foreach/ has a lot of details on point 2) in the comments.

kossebau added a subscriber: kossebau.EditedJul 6 2019, 10:17 AM

@mlaurent Hi, sorry to default to you here, but given the risks with foreach porting (I have done my own share of mistakes in such despite all concentration :) ) https://bugs.kde.org/show_bug.cgi?id=408801 might be triggered by one of this here, have not yet investigated more.
With your mind perhaps still with memories about the code from the foreach porting work, could you given that bug take a look where this might be due to containers being modified in a range-for loop?

I will look at it