aaron.ballman added a comment. In D134550#3813259 <https://reviews.llvm.org/D134550#3813259>, @jyknight wrote:
> I //really// don't think we should have this behavior. The cc1 options are > supposed to be an internal implementation detail. It's already a problem that > the option name doesn't shout "hey I'm an internal interface with no > stability guarantees! Don't use me!". Having clang automatically recommend > these internal options will just make the situation that much worse. > > There are a handful of cc1 options which are sort of "internal but kinda > public" like "-verify" -- things which expected for clang developers, at > least, to use. But there's a great many more which are the interface between > the clang Driver and the clang frontend. Sometimes that interface option > shares the name of a Driver option -- but in many cases it does not. And for > those which do not, we certainly do not want to recommend them to anyone. > > E.g. consider -- if a user types `clang -triple x86_64-linux-gnu`, do we > really want to suggest that they meant `-Xclang -triple`? No way! They should > use the actual driver option `-target`! Similarly for many other cc1-only > options, e.g. `-mrelocation-model`, `-mframe-pointer=`, etc...none of those > should be used or recommended. Thank you for speaking up; this echoes a lot of my concerns. But what convinced me was that we sometimes put experimental options into cc1 with the intent that users can try them out, such as `-fexperimental-max-bitint-width=` and it would be nice for those options to be suggested when the user forgets to add `-Xclang`. Perhaps a different approach is to allow select cc1 options to opt into this suggestion so that we can control which options we are willing to recommend to users? Alternatively, perhaps those experimental options should be exposed from the driver instead of being a cc1-only flag? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134550/new/ https://reviews.llvm.org/D134550 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
