I told you there were failing tests...

I told you there were failing tests...

yes I wanted to look at that.

I do not think it is important that a single line is currently duplicated.

Also as mentioned before I have other changes coming up around the premium stuff so any changes might conflict or become obsolete. I am currently focused on the unmatched suppression stuff and I have other stuff (MinGW, CMake, ...) to look at first before I get around to finish up the code to post a PR.

Also as mentioned before I have other changes coming up around the premium stuff so any changes might conflict or become obsolete

in my humble opinion I dislike to have duplicated code. why would it cause "conflicts" yeah the code might have to be changed but you are going to remove the duplication anyway right? If we have duplication there is a risk that it will be forgotten eventually and will remain. How can you proove that when you will refactor that you will not forget some duplication?

in my humble opinion I dislike to have duplicated code. why would it cause "conflicts" yeah the code might have to be changed but you are going to remove the duplication anyway right? If we have duplication there is a risk that it will be forgotten eventually and will remain. How can you proove that when you will refactor that you will not forget some duplication?

Geez. The PR was just merged two days ago after it had been waiting for feedback for months. And I said that I will look into it. And it is just a single line and that is suddenly the highest priority?!?!?

If you want "proof" I can swamp the repo with PRs which contain intended changes which are hacks and/or incomplete. In this case - see https://github.com/firewave/cppcheck/tree/cfg-name for just some basic changes I threw together.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

in my humble opinion I dislike to have duplicated code.

In that case you also need to get rid of the productname being duplicated in the GUI and the settings otherwise this PR would be incomplete. But that requires other changes ... and other changes. And then you get into how we treat the version wrong etc. That's what my changes are about - it will just be incremental since it affects external stuff (i.e. premium).

Paul wants his CMake stuff in (which requires review), you want a MinGW release (which requires lots of changes) and now discussions about a single duplicated line. And all of it is urgent (which it really isn't). And I am actually working on something which allows us to enable something which has never worked since this project existed and has been years in the making. I do not understand these priorities ...

This should just be a three line change. Everything else will be immediately removed when I post my PR.

Paul wants his CMake stuff in (which requires review), you want a MinGW release (which requires lots of changes) and now discussions about a single duplicated line. And all of it is urgent (which it really isn't). And I am actually working on something which allows us to enable something which has never worked since this project existed and has been years in the making. I do not understand these priorities ...

I believe my MinGW release binary was quite important, as I’ve observed up to 3x speed improvements. If we can be fast it's a strong USP. There is a quite a lot of flux in Cppcheck code to just refactor it. And well it does introduce bugs. We have several user problems—usability concerns, false positives, and so on—that I would personally prioritize investigating. That said, I understand that we all have our own areas of interest and personal “itches” we want to address.

And I am actually working on something which allows us to enable something which has never worked since this project existed and has been years in the making. I do not understand these priorities ...

sounds good of course..

This should just be a three line change. Everything else will be immediately removed when I post my PR.

It is my goal that you remove everything else later when you refactor it. That is not a problem. The problem is if we miss to refactor some place..

I just close this and hope @firewave that you will take a look at the refactorings asap..