fix #11824: Option --max-configs has no effect if -D is used

[clock999]

I have checked the comments on the ticket of the bug. And I simply summarized my logic of checking the configs as below.

The configs that will be totally checked are the sum of the user defined value and the default list. The user defined value and the default list are combined to a total list. The user defined value will be inserted into the total list ahead of the default list.
The user defined value could be empty or not only depends on the -D in the cmdline and the settings in the file imported by --project.
If the --max-config is specified, the total list will have a max length which is the --max-config.
If preprocessOnly is set, only one config in the total list is checked.

[firewave]

This needs a very thorough review as well as tests and documentation (in general and documenting this behavior change). As mentioned in the ticket we might need to fix other things first.

We might also need to print some messages/error if certain configurations are incompatible (I have not looked at it at all yet).

[danmar]

Basically I agree with the idea. If -DFOO --max-configs=2 is used then I would expect that 2 configurations that both define FOO is checked.

You can add an example that clarify this in the manual also:
https://github.com/danmar/cppcheck/blob/main/man/manual.md?plain=1#L386

[danmar]

I would also like to see some regression tests.

[danmar]

I don't remember why we have added Settings::force and Settings::checkAllConfigurations. Isn't it enough with just Settings::maxConfigs?

Imho testcmdlineparser.cpp should test that when --max-config=2 is used then Settings::maxConfigs will be 2 no matter if -D has been used or not.

[danmar]

This code will always execute Preprocessor::getConfigs even if max configs is 1.

[firewave]

I don't remember why we have added Settings::force and Settings::checkAllConfigurations. Isn't it enough with just Settings::maxConfigs?

I think that has been grown historically. It is also possible that part of this is cleaned up with #7293. The duplicated and differing logic in the CLI and GUI code make things a bit awkward.

[danmar]

The duplicated and differing logic in the CLI and GUI code make things a bit awkward.

yes.. if we can unify logic that would make me happy.. :-)

[firewave]

yes.. if we can unify logic that would make me happy.. :-)

Working on it...