In asserted builds, we do a so-called "round-tripping". This is called
from CompilerInvocation::CreateFromArgs, which eventually calls
generateCC1CommandLine from the lambda. That, in turn, calls a bunch
of GenerateXXX functions, thus ours as well: GenerateAnalyzerArgs.
The round tripping ensures some consistency property, also that the
generator generates the arguments in a deterministic order.
This works at the moment, but as soon as we add a new AnalyzerOption to
the AnalyzerOptions.def file, it's pretty likely that it will produce
the same sequence of args BUT in a different order for the second round
of round-tripping, resulting in an err_cc1_round_trip_mismatch
diagnostic.
This happens because inside GenerateAnalyzerArgs, we iterate over the
Opts.Config, which is of type StringMap. Well, the iteration order
is not guaranteed to be deterministic for that. Quote
https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h
StringMap iteration order, however, is not guaranteed to be
deterministic, so any uses which require that should instead use a
std::map.
Consequently, to allow adding/removing analyzer options to
AnalyzerOptions.def without relying on the current iteration order, we
need to make that deterministic. And that is what I'm proposing in this
patch.