feat(compiler-optimisation): in-tree frontend optnone injection + clean diagnostics in compiler wrapper #29
Description
Type: Feature
Priority: Medium
Context
We added an in-tree Clang frontend action to inject optnone/noinline on user functions for analysis stability, without relying on a dynamic plugin. This is needed to preserve IR structure when running analysis (e.g., duplicate else-if detection) and to reduce noise from compiler argument conflicts.
Goals
Add a first-party frontend path (no .so) that annotates functions with optnone/noinline.
Provide CLI toggles (--ct-optnone, --ct-no-optnone).
Avoid warning noise when compilation happens in memory (-c unused, -disable-O0-optnone ignored).
Implementation Summary
New frontend module with ASTConsumer and OptNoneAction wrapper around EmitLLVM* actions.
Annotation done early (HandleTopLevelDecl, HandleInlineFunctionDefinition) to ensure codegen sees attributes.
Added config flag + help output.
Added conflict warning for --ct-optnone + -disable-O0-optnone.
In ToMemory mode, strip -c and -disable-O0-optnone to avoid clang unused-arg warnings.
Fixed a UAF caused by destroying CodeGenAction before consuming the module (module now consumed while action is alive).
Acceptance Criteria
Running cc --ct-optnone -emit-llvm -S shows optnone in IR even with -Xclang -disable-O0-optnone.
No clang warnings for -c or -disable-O0-optnone in --in-mem / ToMemory.
No ASAN issues during in-memory compilation.
CLI help lists --ct-optnone / --ct-no-optnone.
Notes
-O0 adds optnone by default; --ct-optnone forces it regardless of -disable-O0-optnone.
Warn when arguments conflict.