Support C++ Core Check improvements in Visual Studio 2017 15.5

[guwirth]

In Visual Studio 2017 version 15.5 Preview 4 Microsoft have refreshed their C++ Core Guidelines Check extension for native code static analysis tools.

https://blogs.msdn.microsoft.com/vcblog/2017/11/15/c-core-check-improvements-in-visual-studio-2017-15-5/

New rules in each set

Class rules
    C26432 DEFINE_OR_DELETE_SPECIAL_OPS Special operations (e.g. destructors or copy constructors) imply special behavior and should come in complete sets to define such behavior clearly.
    C26436 NEED_VIRTUAL_DTOR Having virtual methods suggests polymorphic behavior which requires more careful management of object cleanups.
    C26434 DONT_HIDE_METHODS Hiding methods by names is like hiding variables. Naming should not lead to ambiguity.
Concurrency rules
    C26441 NO_UNNAMED_GUARDS Guard objects must be assigned to local variables with proper scope and never left as temporaries.This rule tries to target the most common cases of locks misuse mentioned in the talk on CppCon 2017: Louis Brandy “Curiously Recurring C++ Bugs at Facebook”.
Declaration rules
    C26426 NO_GLOBAL_INIT_CALLS Calling a function from the initializer for a global variable may lead to unexpected results due to undefined order of initialization.
    C26427 NO_GLOBAL_INIT_EXTERNS Global variables should not refer to external symbols to avoid initialization order problems.
Function rules
    C26439 SPECIAL_NOEXCEPT Some of the special functions (like destructors) should avoid throwing exceptions.
    C26440 DECLARE_NOEXCEPT If a function neither throws nor calls other functions that can throw, it should be marked as noexcept.
Resource management rules
    C26416 NO_RVALUE_REF_SHARED_PTR Passing shared pointers by rvalue-reference is unnecessary and usually indicates a misuse of shared pointers. Shared pointers are safe and inexpensive to pass by value.
    C26417 NO_LVALUE_REF_SHARED_PTR A shared pointer passed by reference acts as an output parameter, and it is expected that its ownership will be updated in the function (e.g. by calling reset()). If the shared pointer is only used to access its contained object, a plain reference or pointer to the contained object should be passed instead.
    C26418 NO_VALUE_OR_CONST_REF_SHARED_PTR When a shared pointer is passed by value or reference to const, it indicates to the caller that the function needs to control the lifetime of its contained object without affecting the calling code. However, if the smart pointer is never copied, moved, or otherwise modified in a way that will affect the contained object’s lifetime, a plain reference or pointer to the contained object should be passed instead.
    C26415 SMART_PTR_NOT_NEEDED Smart pointers are convenient for resource management, but when they are used only to access the contained object, the code may be simplified by passing plain references or pointers to the contained object instead.
    C26414 RESET_LOCAL_SMART_PTR Using a local smart pointer implies the function needs to control the lifetime of the contained object. If a function does not use the smart pointer to pass ownership outside of the function and has no explicit calls to change ownership, a stack-allocated local variable should be used instead to avoid an unnecessary heap allocation.
    C26429 USE_NOTNULL If a pointer is dereferenced but never tested for nullness, it may be useful to use gsl::not_null so that assumptions about its validity are properly asserted.
    C26430 TEST_ON_ALL_PATHS If a pointer is dereferenced and tested in at least one path, the code should ensure it is tested on all paths since testing implies possibility that the pointer is null.
    C26431 DONT_TEST_NOTNULL Testing for nullness of expressions of type gsl::not_null is obviously unnecessary.
Style rules
    C26438 NO_GOTO Modern C++ should never use goto in user-written code.
Type rules
    C26437 DONT_SLICE Even though compiler allows implicit slicing, it is usually unsafe and unmaintainable.
    C26472 NO_CASTS_FOR_ARITHMETIC_CONVERSION Static casts can silently discard data which doesn’t fit into an arithmetic type.
    C26473 NO_IDENTITY_CAST Casting between pointers of exactly same type is obviously unnecessary.
    C26474 NO_IMPLICIT_CAST Casting should be omitted in cases where pointer conversion is done implicitly. Note, the rule ID is a bit misleading: it should be interpreted as “implicit cast is not used where it is acceptable”.
    C26475 NO_FUNCTION_STYLE_CASTS Function-style cast is another form of a C-style cast and can lead to silent data truncation.

Warnings that were rearranged

Some warning numbers found in the VS2017 version 15.3 release are no longer available in VS2017 version 15.5. These warnings did not disappear, but were rather replaced with more specific checks. The primary goal was to separate particularly common patterns within a warning into separate warnings.

C26461 USE_CONST_INPUT_ARGUMENTS is replaced by more specific warnings:
    C26460 USE_CONST_REFERENCE_ARGUMENTS
    C26461 USE_CONST_POINTER_ARGUMENTS
C26470 NO_REINTERPRET_CAST_TO_VOID_PTR has been removed and is replaced by parts of the logic of two new warnings. Similarly, C26490 NO_REINTERPRET_CAST has been narrowed to cover only cases that are not covered by these new warnings.
    C26473 NO_IDENTITY_CAST
    C26474 NO_IMPLICIT_CAST
C26496 USE_CONST_FOR_VARIABLE is narrowed to non-pointer values; the remaining is split into specific warnings:
    C26462 USE_CONST_POINTER_FOR_VARIABLE
    C26463 USE_CONST_FOR_ELEMENTS
    C26464 USE_CONST_POINTER_FOR_ELEMENTS
C26492 NO_CONST_CAST is narrowed to effective casts; for other cases there is specific warning:
    C26465 NO_CONST_CAST_UNNECESSARY
C26491 NO_STATIC_DOWNCAST is narrowed to non-polymorphic types; polymorphic type casts are flagged by a specific warning:
    C26466 NO_STATIC_DOWNCAST_POLYMORPHIC