@Martin_fr some of these bugs are not related to Trunk as you said. One like #41431 was reported numerous times by you, me and others from 2017!
True, but the point is that in trunk there can (at times) be more. And that is not just a theoretical issue.
Right now, I would recommend 3.2.3. Chances (extremely high) are that the number of fixed compiler bugs (several, compared to 3.2.2) outnumber any potential new ones (and given its a fixes branch, new ones are possible but less likely).
But that aside, trunk is a gamble.
Same for Lazarus. Even though I myself would say its most of the time stable (I use it, and rarely have issues), I was just reminded how wrong that feeling is. The last - I guess - 2 month, the editor had been unstable. But it had taken about that time before any error caused by that, has manifested for me (despite I compile with asserts, that actually eventually caught it). So I would have told everyone, its fine, you can pick any commit and run it.
What I understood from it is that not much people write inline code otherwise it would be solved by now.
Well, not every inline code fails, and even if inlined code is broken, it must still be called in a way were the error manifests.
I caught the "inline (nested) treats params as var params" bug in my test. But without the test, I might not have noticed. For most of the data, the code still worked. But the testcase luckily contained data that run into the error.
And then, its very hard to measure how many people are affected by a compiler bug like that.
Most people, if they get an error from it, will likely not attribute it to the compiler. It takes a lot of very different debugging to make that connection.
So my guess: Most people will just think, their code is wrong, and if they can't figure the exact cause they just rewrite it, and get something working. That is, if they notice that their app is broken, if they just get the odd, annual user feedback about some obscure error, they may just be forced to ignore it if they can't ever reproduce it.
Can I ask how do you manage automatic tests?
Most of them are unit test. Some are running the full product in a real or mock setup. "Automatic" here doesn't mean CI (though some of the tests for my Lazarus work, do now run on GitLab CI, but that wasn't what I referred too). So the tests are still started manually.
"Automatic" in this case is the difference to "manual product testing" => That is, testing is not just building the final product, and going through a checklist (open a file, perform foo and bar). Rather it is having the test trigger all that code.
And most tests I have, run (nested) loops with different (combination of) data => so the tests can easily do thousands of calls to the tested code. Ensuring to trigger as many cases as possible (trying to reach high coverage, not just for codelines, but also for conditions and sub-conditions, as well as combinations and variations of branches / unfortunately we don't have tools to measure those).
Many of my tests can be run from console. So then the test can run in lots of buildmodes, and I have a script that runs it in all of them (that will run for some time, but that happens in the background).
Primarily that was for finding my own mistakes, so I could run with all different levels of -gt. And I could run with/without -gh (as gh can hide pointer errors).
Even different optimization levers could help find dangling pointers (as mem layout changes, changes go up that a dangling pointer hits something that makes it noticeable).
But the different optimization levels, combined with all the other switches, ended up revealing the compiler bugs.
Had I just done my basic test runs from the IDE (using O1, so I can debug any error if the tests raises an exception), then I would never have noticed them.
Recent
