jansvoboda11 wrote: > > I'm not suggesting to treat CodeGenOptions as incompatible by default. > > I think the naming might be adding to the confusion here. We now have > `COMPATIBLE_..._CODEGENOPT`, but it's the "compatible" ones that are > impacting the AST and not being cleared in `resetNonModularOptions`. We have > no non-compatible but affecting options to compare to. I think the old name > was easier to understand.
That's a good point. Would you have a different opinion if I told you that the next PR in my queue re-introduces `AFFECTING_*_CODEGENOPT` to represent the affecting `ENUM_LANGOPT(ExceptionHandling, ...`? Then we'd have: * `LANGOPT` == `AFFECTING_CODEGENOPT` * `COMPATIBLE_LANGOPT` == `COMPATIBLE_CODEGENOPT` * `BENIGN_LANGOPT` == `CODEGENOPT` This makes `COMPATIBLE_` have the same semantic in both, with defaults being different. I'm fine with the defaults being different, since in my mind, language options typically do affect the AST, while codegen options typically do not.) (FWIW I'm, working on simplifying the hierarchy of `LANGOPT` macros so that the "effect on AST" is an explicit argument to the X macro. If we apply the same concept on `CODEGENOPT`, I think that gets us into a reasonable place where the naming is consistent between both and everything is explicit. https://github.com/jansvoboda11/llvm-project/commit/3789122f0475cf4217e1fe1028b9079ca4d4200b) https://github.com/llvm/llvm-project/pull/146422 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
