AaronBallman wrote: > I'm actually wondering now whether we should have a generic > `ext_warn_old_extension_now_standardised` rather than requiring every new > additional extension warning be manually adopted by every project using clang?
I'm not strongly opposed but I also don't think it's a problem that needs a general solution. That said, I am weakly opposed to the idea because it doesn't make sense to me in terms of use case. This diagnostic reads to me as: "please tell me about all my extensions, except the ones that a committee standardized in a language mode I'm not currently using" and I don't see how that's valuable except in a "I didn't know what I was asking for when I enabled pedantic diagnostics" kind of use case. I think the pain here comes from people expecting `__COUNTER__` to have already been sufficiently portable to have not been an extension at all and given that C++ is down to only 3-4 implementations (which all supported this extension), perhaps that's a better design consideration -- if every C++ implementation supports it, perhaps we should only diagnose it under some `-super-pedantic` mode. But this is RFC territory either way because `-pedantic` has a well-established behavior and we shouldn't change the design of it without significant buy-in. > Actually, as I write this, I think what we actually need is something similar > to the deprecation pipeline, at least for `-Werror` users (I recognize that > the argument here is that they definitionally want warnings as errors, but I > would argue that there's a meaningful difference between a new - useful - > diagnostic, and a feature that has been in use for decades suddenly being > labeled an extension+error), maybe something along the lines of: This diagnostic is useful; that you don't find it useful because of the particulars of your situation does not make it stop being useful in general. There are implementations which do not support `__COUNTER__` as an extension and the *only purpose* to `-pedantic` is to tell you about use of extensions for strictly conforming programs so that you can make a decision as to whether your code is sufficiently portable for your use cases. That's going to differ from user to user and extension to extension. > > 1. DefaultWarnNoWerror, with a note saying "this will become an error > under `-Werror` in future, if -Werror is enabled > > 2. One release later drop `DefaultWarnNoWerror` > > > This gives a window for people who do want the -Werror to change their code, > and the people who don't to add the `-Wno-error=...`before it bites. I think this is a reasonable idea to consider for the diagnostics engine in general; perhaps it even makes sense to have a policy that any pre-existing warning diagnostic that gets changed to be enabled by default should have this flag for one release. We'd have to think about how to handle omnibus flags though. e.g., if we move something off-by-default into a bigger group and the group gets upgraded, what should happen when the omnibus is explicitly upgraded like `-Werror=most`? https://github.com/llvm/llvm-project/pull/218669 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
