Detect and fix warnings that are found by IntelliSense code analysis

[javagl]

^{As a follow-up of #27 (comment) :}

The current warning level for MSVC is set to a nicely strict /W4 at the moment. But there are still some warnings generated only by IntelliSense in Visual Studio (i.e. not during the compilation, and not by IntelliSense in VS Code).

The goal of this issue is to find out how these warnings can be caught during the compilation process.

This has the caveat that there will be many warnings due to include of Third-Party headers, but it should be possible to avoid most of them via "pragma guards", as it is done in https://github.com/CesiumGS/cesium-native/blob/master/CesiumUtility/include/CesiumUtility/Json.h . If it is easily possible to simply omit the warnings that are created by the draco compilation, that would also be nice.

[javagl]

I had a look at the options here, based on https://docs.microsoft.com/en-us/cpp/build/reference/analyze-code-analysis?view=msvc-160 . We can change the target_compile_options for MSVC to

    target_compile_options(${targetName} PRIVATE /W4 /WX /wd4201 /analyze /analyze:WX- /analyze:plugin"EspXEngine.dll" /experimental:external /external:I ../../../cesium-native/extern /external:anglebrackets)

Unfortunately, the external parts (which are supposed to omit everything from the extern directory) do not fully work. They seem to have an effect, but not filter out everything. For example, they don't filter out the rapidjson warnings (and there are lots of them). A workaround is to manually filter the output, based on the "File" column, in the Error/Warnings list in the VS IDE.

At the time of writing this, even the filtered list will show approximately 4000 warnings in cesium-native 😬

Fortunately, most of them are trivial. From a quick look, several thousand are of the categories

• The variable x is assigned only once, mark it as const
• Function x should specify exactly one of 'virtual', 'override', or 'final'
  These are mostly caused by the auto-generated functions in CesiumGltfReader, which are usually virtual and override
• Function x can be declared 'noexcept'
  and
  Default constructor may not throw. Declare it 'noexcept'
  (also many of them in the auto-generated classes)
• Lots of cast nitpicking....

But there are also some important ones, for example:

• The function is declared 'noexcept', but calls function x:, which may throw exceptions

(and there are surprisingly many of these). Being somewhat related to #212 , this should be carefully reviewed.

[lilleyse]

I think this can be closed. Once we add support for clang-tidy we should be able to configure IntelliSense to use clang-tidy instead of its built in code analysis.

CC #203