After a revision of D96274 changed DiagnosticOptions to not store all remark arguments as-written, it is no longer possible to reconstruct the arguments accurately from the class.
This is caused by the fact that for -Rpass=regexp and friends, DiagnosticOptions store only the group name pass and not regexp. This is the same representation used for the plain -Rpass argument.
Note that each argument must be generated exactly once in CompilerInvocation::generateCC1CommandLine, otherwise each subsequent call would produce more arguments than the previous one. Currently this works out because of the way RoundTrip splits the responsibilities for certain arguments based on what arguments were queried during parsing. However, this invariant breaks when we move to single round-trip for the whole CompilerInvocation.
This patch ensures that for one -Rpass=regexp argument, we don't generate two arguments (-Rpass from DiagnosticOptions and -Rpass=regexp from CodeGenOptions) by shifting the responsibility for handling both cases to CodeGenOptions. To distinguish between the cases correctly, additional information is stored in CodeGenOptions.
The CodeGenOptions parser of -Rpass[=regexp] arguments also looks at -Rno-pass and -R[no-]everything, which is necessary for generating the correct argument regardless of the ordering of CodeGenOptions/DiagnosticOptions parsing/generation.
Can this just be a Kind field in RemarkPattern?