report internalError when command execution returns errorcode / also some related cleanups and tests

[firewave]

Encountered while investigating https://trac.cppcheck.net/ticket/11708.

This has been like this since the introduction of internalError in b6bcdf2 (almost ten years ago to the day). Logging internal errors which bail out(!) of the analysis simply to std::cout for them possibly never to be seen (and also not affected the exitcode) is pretty bad IMO. They should always be visible.

I also removed the filename from the message as it is already available (and thus redundant) and its existence should be defined by the template.

[firewave]

We probably should clean up the message a bit more. It is pretty redundant. There's even a case where it states again that an internal error happened which would lead to three instances of it in the message.

[danmar]

I close this draft PR..

With b086873 I change the severity to error and report these in the normal Cppcheck error output.

Feel free to point out if there is something missing..

[firewave]

Will take a look at the other PR but this contained much more which should still be applied.

[firewave]

The failing job is caused by not being able to download our own 2.8 source archive from GitHub. It works locally so I assume it is a temporary issue. I will trigger the job again later.

[firewave]

The RAII closing of the pipe causes a debug assertion in Visual Studio so I changed the errorhandling:

I had that queued up for another PR anyways and will add the proper error reporting in that.

[danmar]

I think this looks promising. It seems to me that it's really important that there is some kind of critical error if the addon fails. I'm not sure what behavior you saw, did Cppcheck exit happily?

The RAII closing of the pipe causes a debug assertion in Visual Studio so I changed the errorhandling:

hmm spontanously I don't understand why there would be a debug assertion when the RAII code closes the pipe. Feel free to enlighten me.

[firewave]

I think this looks promising. It seems to me that it's really important that there is some kind of critical error if the addon fails. I'm not sure what behavior you saw, did Cppcheck exit happily?

We at least ignored the exitcode of the command. More information coming in a different PR.
I have been cleaning up the addon errorhandling in that but had lots of issues forcing errors so I keep losing motivation very fast.

hmm spontanously I don't understand why there would be a debug assertion when the RAII code closes the pipe. Feel free to enlighten me.

I assumed it was an issue when an invalid handle was passed into the close function but it turns out it asserts when the given executable doesn't exist on open since it tries to close some invalid internal lock within the Windows runtime code.
But the RAII code hid the actual exitcode of the command as mentioned above.