================ @@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"], "code-completion-with-fixits">, def skip_function_bodies : Flag<["-"], "skip-function-bodies">, HelpText<"Skip function bodies when possible">, MarshallingInfoFlag<FrontendOpts<"SkipFunctionBodies">>; -def disable_free : Flag<["-"], "disable-free">, - HelpText<"Disable freeing of memory on exit">, - MarshallingInfoFlag<FrontendOpts<"DisableFree">>; +defm disable_free : BoolOption<"", + "disable-free", + FrontendOpts<"DisableFree">, + DefaultFalse, + PosFlag<SetTrue, [], [ClangOption], "Disable">, + NegFlag<SetFalse, [], [ClangOption], "Don't disable">, + BothFlags<[], [ClangOption], " freeing of memory on exit">>; ---------------- zygoloid wrote:
This is currently defined in a block of CC1-only options. If we want to expose this as a driver option, that should be done by moving it elsewhere in the file rather than by specifying `[ClangOption]` here. Though it's not clear to me if this is intended to be a driver option: `ClangOption` suggests yes, but the test using `-Xclang` suggests no. If this is supposed to be a driver flag, those are usually namespaced by their initial letter, so I think it's worth considering if a namespace would make sense here too. If this only controls the behavior of the frontend then using a `-f` prefix might make sense, but I suppose we might also want to make this control the behavior of the driver itself, so maybe an unnamespaced flag is appropriate. GCC interprets `-disable-free` as [enabling debugging dumps](https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Developer-Options.html) at phases `i`, `s`, `a`, `b`, ... of processing, so there's not a collision to worry about there. The double-negative in `-no-disable-free` also seems a bit funny, but it's probably fine :) https://github.com/llvm/llvm-project/pull/136213 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
