danmar
deprecated `--enable=style` implying `warning`, `performance` and `portability`
This finally makes all those groups granular from each other.
We can still move the version which will remove this behavior if we feel uncomfortable. But we should at least finally deprecate it.
I removed the CI files so this does not trigger a build to ease things. So please review the individual commits as the CI changes are not visible.
I don't know. I agree in theory that it is confusing that "style" enables all the other severities.
But I have a bad feeling about destroying the command line interface. According to our website we should consider:
- Buildbot - integrated
- CLion - Cppcheck plugin
- Code::Blocks - integrated
- CodeDX (software assurance tool) - integrated
- CodeLite - integrated
- CppDepend 5 - integrated
- Eclipse - Cppcheclipse
- gedit - gedit plugin
- github - Codacy and SoftaCheck
- Hudson - Cppcheck Plugin
- Jenkins - Cppcheck Plugin
- KDevelop - integrated since v5.1
- Mercurial (Linux) - pre-commit hook - Check for new errors on commit (requires interactive terminal)
- QtCreator - Qt Project Tool (qpt)
- Tortoise SVN - Adding a pre-commit hook script
- Visual Studio - Visual Studio plugin
I fear some of these are not actively maintained
Valid point. But as it doesn't change the behavior there should be no issues. So we could still deprecate this but remove the version number. We have done so with several things which could affect that.
I tried figuring out something which is not as soft as still allows this to be transitional. Maybe we need a --no-deprecated switch which will error out on such things whereas the default behavior is just a message for the transitional period. Or raises analysis errors/warnings and not simply messages to stdout/stderr. That would increase the visibility even in head-less systems.
But I think we already killed those unmaintained with several changes which will now fail an analysis / raise an error by default which previously did not.
But as it doesn't change the behavior there should be no issues.
I don't understand.. if the plugin just uses --enable=style then the behavior will change.
But I think we already killed those unmaintained with several changes which will now fail an analysis / raise an error by default which previously did not.
Yeah perhaps.. do you know any particular change that could break plugins?
The color coding comes to my mind directly but I have the feeling plugins often use xml..
As most users won't see the message we should refrain from actually specifying a target until we are able to actually properly communicate this to the user. I have an idea on how to do that but it will be a while. I will file a ticket about that soon.
I would still like to deprecate this without a target version as this is really misleading and needs to be cleaned up. And we obviously need to specify the proper intent in our own code. Will update it soon.