jhuber6 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. Thanks for bringing up your concerns. I think the question is mostly what we want to be exposed to the users. As you mentioned there are several options that have implementations in the driver and shouldn't be called directly by the user. We definitely do not want to encourage users to use CC1 options that have driver equivalents. We could assume that the user would be aware that anything requiring `-Xclang` is a manual override, but many users may just see that as a way to get the behaviour they want without knowing about the expected option. If you think this is not desirable go ahead and revert the patch, I won't complain. In D134550#3813269 <https://reviews.llvm.org/D134550#3813269>, @aaron.ballman wrote: > 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? I generally think the check added in this review is useful, but this is speaking as a developer. Adding a special flag that enables this behavior might be helpful, but it would require some more justification for the extra work I'd say. 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
