[all-commits] [llvm/llvm-project] b8e1da: [analyzer] Initialize ShouldEmitErrorsOnInvalidCon...

[Balazs Benics via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b8e1da050673470f20a75d4ecca2c0a00d1a8691
      https://github.com/llvm/llvm-project/commit/b8e1da050673470f20a75d4ecca2c0a00d1a8691
  Author: Balazs Benics <benicsbalazs at gmail.com>
  Date:   2022-09-14 (Wed, 14 Sep 2022)

  Changed paths:
    M clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h

  Log Message:
  -----------
  [analyzer] Initialize ShouldEmitErrorsOnInvalidConfigValue analyzer option

Downstream users who doesn't make use of the clang cc1 frontend for
commandline argument parsing, won't benefit from the Marshalling
provided default initialization of the AnalyzerOptions entries. More
about this later.
Those analyzer option fields, as they are bitfields, cannot be default
initialized at the declaration (prior c++20), hence they are initialized
at the constructor.
The only problem is that `ShouldEmitErrorsOnInvalidConfigValue` was
forgotten.

In this patch I'm proposing to initialize that field with the rest.

Note that this value is read by
`CheckerRegistry.cpp:insertAndValidate()`.
The analyzer options are initialized by the marshalling at
`CompilerInvocation.cpp:GenerateAnalyzerArgs()` by the expansion of the
`ANALYZER_OPTION_WITH_MARSHALLING` xmacro to the appropriate default
value regardless of the constructor initialized list which I'm touching.
Due to that this only affects users using CSA as a library, without
serious effort, I believe we cannot test this.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D133851