[Mlir-commits] [mlir] [mlir] Apply the default --split-input-file marker after parsing (PR #226361)

[Fangrui Song]

MaskRay wrote:

> Can you clarify why is cl::callback a problem and should be removed as a feature?
> 
> The new the replacement pattern you're applying here seems inferior to me as it decouples this from the option description definition, every user of the parser now needs to handle the callback themselves.
> 
> I started looking at discourse, but I have to say there are lots of threads, and the general direction is not clear.
> 
> A lot of those threads are about the LLVM used of `cl::` involving a lot of global state and static initializer, which MLIR has been avoiding by designing it better from the start.
> 
> It's not clear to me what the general direction and the end state for `cl::` management in MLIR?

`cl::callback` runs arbitrary code while argv is being parsed.
https://discourse.llvm.org/t/rfc-declare-library-command-line-options-in-tablegen-one-struct-per-library/91877 moves library options to .td declarations that generate a plain struct per library, and a declaration has nowhere to put code, so every callback becomes either data or explicit post-parse logic.
Here it becomes data: in the .td form, `--split-input-file` is a flag whose value is the default marker plus a --split-input-file=<marker> spelling.
This patch is the interim step while MlirOptMainConfig's options are still cl::opt.

On the end state for MLIR: the `register*CLOptions()` structs (MLIRContext, AsmPrinter, PassManager, Timing, debug) map directly onto (trivially copyable/destructible) per-library option structs.
Registration stays explicit and opt-in, with no global constructors, which matches MLIR's design. Pass options are per instance and parsed from pipeline strings, so they are unaffected; the only cl:: hook they use, `setCallback` for `optHasValue`, moves to handleOccurrence.


https://github.com/llvm/llvm-project/pull/226361