Report all warnings in CI builds

[jhlegarreta]

Description

Compiling ITK on MSVC with the /Wall flag raises a number of warnings that are not being reported in our CI builds. We should at least report or monitor them to try to address them as time permits.

Steps to Reproduce

Add the relevant warnings (e.g. /Wall) to the compilers to report all warnings.

Expected behavior

We monitor all source code warnings.

Actual behavior

Not all source code warnings are being monitored.

Reproducibility

N/A.

Versions

master.

Environment

Any.

Additional Information

Cross-referencing #4865 (comment).

[jhlegarreta]

Cross-ref #4865 (comment):

I tried it locally, only to see no new warnings.

Here is the screenshot of my compiler's output:

I will try to post my CMakeCache.txt to see if that helps explaining the difference.

Here it is: CMakeCache.txt

[N-Dekker]

I do like to see all those warnings, thanks 👍 However, I don't think it's necessary to fix all of them. MSVC /Wall produces a lot of noise. Most of those /Wall warnings do not indicate a serious problem in the code.

MSVC /Wall enables compiler warnings that are off by default. Its description says:

The compiler supports warnings that are turned off by default, because most developers don't find them useful.

[jhlegarreta]

MSVC /Wall produces a lot of noise. Most of those /Wall warnings do not indicate a serious problem in the code.

Probably, but the example in #4865 speaks for itself. And I also saw some warnings related to unused variables and signedness comparison mismatches.

[N-Dekker]

the example in #4865 speaks for itself

• Just some thought here... Issue Compilation error while using itk::RelabelComponentImageFilte::GetSizeOfObjectInPhysicalUnits #4865 was especially interesting because it triggered the question, whether we really want RelabelComponentImageFilter to support signed pixel types. (The answer was yes!) The warning itself could have been ignored safely (fortunately). Of course, it's nicer to address the warning, as pull request COMP: Fix compilation issue when using RelabelComponentImageFilter #4866 did

If you really want to address all those /Wall warnings, can you please do it in small steps, one warning category per PR? (Rather than having one "mega PR" for all warnings.) I find it difficult to review large PRs. And warnings can often be addressed in multiple ways, which may need to be discussed before merging.

[jhlegarreta]

If you really want to address all those /Wall warnings, can you please do it in small steps, one warning category per PR?

Niels, please, I did not say that I will attempt at fixing all warnings, but I believe that unless we see such warnings openly somewhere it is impossible to assess what we are ignoring. I have a list of other things that I have been unable to address in ITK since some time now. Also, I know very well the time it would require to have a look at the 5000+ warnings that I get from /Wall... You have seen my PRs in the past and I believe both PRs and commits have been clean enough, and commit messages good enough to give the necessary context to reviewers, and addressing one problem at a time. Thanks for understanding.

[kenavolic]

Just for notice, as ITK consumers, we can handle ITK headers as system headers to avoid warnings.