Daniel Marjamäki

> IMO it is utter madness to have two different implementations of something as it means we have to provide performance and quality for both of them. Right now there...

wait.. it's not valid syntax. I don't think our checkautovariables should handle this garbage. you can add a syntax checking in the tokenizer. however .. we do want to handle...

> Also didn't we already add such code? I remember having a discussion with @danmar about something similar (with me having quite some opinion on this). I don't know.. I...

> with me having quite some opinion on this @firewave sorry but I don't have the discussion in my head.. please feel free to comment on this. * This approach...

firewave has made an effort to make sure tests can be executed from different folders. As your test is written I fear it must be executed from inside test/cli folder.

@firewave > but I still think it should be caught earlier. Overall I think that it is a good strategy to fail immediately/early... But we should probably think more carefully...

> These are not a false positives. The analysis looks at the code and if it sees that the return value is used in most cases it flags it as...

> Is this the right direction? What should be the implementations? Should all calls to mSettings.nomsg.isSuppressed(errorMessage) actually be calls to the new function? I don't feel I remember all the...

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....

> 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.