awarzynski added a comment. Apologies, it has taken me a bit longer to get back to this. @jansvoboda11 , now I'm realising the key disadvantage of using `OptInFFlag/OptOutFFlag` - it's impossible to express the `opt-in`/`opt-out` semantics in TableGen. In fact, only the contents of `clang -cc1 --help` are being tweaked by using `OptInFFlag/OptOutFFlag`. Basically:
- for `OptInFFlang`, only `-ffoo` is printed with `-clang -cc1 --help` (the help text for `-ffno-foo` becomes irrelevant) - for `OptOutFFlang`, only `-fno-foo` is printed with `-clang -cc1 --help` (the help text for `-ffoo` is irrelevant) IIUC, this is achieved through `flags` (`CC1Option` vs `[]`). In Flang, we rely on the fact that "no help text? don't include it in `flang-new -fc1 --help`" instead. This behavior is implemented in `clangDriver` and applies to all drivers that use it (so this is nothing specific to Flang). This way, we can always mark Flang options with the relevant flags (e.g. `FC1Option`). In other words, we can claim them and make it clear that other drivers can ignore them. In general, I think that Options.td would become a bit cleaner and easier to reason about if all options specified all their flags. That wouldn't be easy to achieve though! I'm just about send an updated patch. It takes into account the points that I raised above ^^^. It also fixes the failing tests reported by @PeteSteinfeld. Does this new approach work for Clang (I quickly tested `clang -cc1 --help` and see no difference)? It would be nicer to have the `opt-in`/`opt-out` semantics for Flang in TableGen through something similar to `BoolFOption`. No need for this just now - one step at a time :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105881/new/ https://reviews.llvm.org/D105881 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
