zmodem wrote: > Isn't that exactly what we did now just one release sooner? Why would it be > any less painful if we shifted everything by half a year?
The difference is that there'd be a gap between introducing the new attribute and deprecating the old one, so people could start migrating early. Also the separate -Wno- flag. Thanks for the background, Aaron, this is helpful for understanding the motivation. > I'm not certain that we should add a separate deprecation flag; the reasoning > for the group applies to every thing we deprecate. The point of deprecation > warnings isn't to make it trivial for the user to disable them, it's to annoy > the user into updating their code so that the deprecated thing can eventually > be removed. The issue is that `-Wno-deprecated-attributes` is a big hammer, and enabling it could cause us to miss *other* deprecated attributes while we migrate. (Maybe @usx95 can fix Abseil :-) I understand that it's not desirable to keep adding flags all the time, but it would be helpful for us. > To be clear, if deprecating these attributes really is an intractably painful > thing It's not intractable of course, it's just more disruptive. Another aspect is that we don't even build with -Wlifetime-safety enabled, and this attribute (via third-party code or otherwise) is all gated behind `__has_cpp_attribute`, so why should we be hit by this? Maybe these attributes should not be available when the feature is off? That would at least limit the impact of these changes to those who actually use the extension. Perhaps that would be useful to the developers of this feature as well, as they could then explore the design space of the extension a bit more freely. https://github.com/llvm/llvm-project/pull/196635 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
