[clang] Make the `-disable-free` flag more full featured (PR #136213)

[Richard Smith via cfe-commits]

================
@@ -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