[clang] Simplify updating CodeGenOptions

[hahnjo]

This works now since upstream commit llvm/llvm-project@ddeab07 changed the intentional copy in CodeGeneratorImpl to a reference with a single copy of the CodeGenOptions stored in the CompilerInvocation.

This reverts the downstream modifications from commit 0d60867, allowing to drop one more Clang patch.

[vgvassilev]

This very likely renders #pragma cling optimize (2) dysfunctional.

[hahnjo]

This very likely renders #pragma cling optimize (2) dysfunctional.

No, it doesn't: there is a single CodeGenOptions that is updated in IncrementalParser::codeGenTransaction, see the commit message.

[vgvassilev]

Assuming you checked, then LGTM!

[vgvassilev]

LGTM!

[hahnjo]

Assuming you checked, then LGTM!

Yes, I checked by inspecting the value of CodeGenOpts.OptimizationLevel in StartModule (without passing the updated options). However, I suspect that's actually too late for some code generation, see #23220. But that's already the case for master, unrelated to this change.

[vgvassilev]

That's a silent regression introduced along the upgrades I guess. It is a pity that rootbench is good state to catch that and we never implemented adequate cling test...

[hahnjo]

That's a silent regression introduced along the upgrades

Not a recent one, I can reproduce also with 6.26. To be honest, I would not be super surprised if this oversight is there since the feature was introduced. To be clear, the optimization level is respected for the majority of the compilation, such as the passes, but not (always) for generating the IR.