[libcxx-commits] [PATCH] D62428: [libcxx] Slightly improved policy for handling experimental features

Fri May 31 10:28:19 PDT 2019

dexonsmith added a comment.

In D62428#1525189 <https://reviews.llvm.org/D62428#1525189>, @mclow.lists wrote:

> In D62428#1519664 <https://reviews.llvm.org/D62428#1519664>, @jfb wrote:
>
> > In D62428#1518488 <https://reviews.llvm.org/D62428#1518488>, @mclow.lists wrote:
> >
> > > The deletions are fine, the doc updates are good, but I think deprecation warnings are not.
> > >  Things that are going to happen in the future (a year from now, say) or never (if people don't update their tools) don't belong in the warning spew for **every single build**
> >
>

I don't understand your point here Marshall.  Why would this cause spew for every build?  Users can choose to change their code, or to opt-out of the diagnostic.

If this opt-out mechanism isn't quite right, we can invent new ones.  For example, we could use `__attribute__((deprecated))` or extend `__attribute__((availability))` somehow so that the diagnostics are bucketed under `-Wdeprecated`.  We could create a special `-Wdeprecated-experimental` diagnostic so users can opt-out of (or -in to, via `-Wno-deprecated -Wdeprecated-experimental`) just those.

>> Similar deprecation warnings are pretty common coming from clang (both for standard things as well as extensions / builtins). What Louis proposes seems consistent with what the compiler does. Do you think there's a better approach that libc++ could take?
> 
> I think they're wrong there, too. 
>  I've enumerated why I believe so on the ML, and in Slack (several times), so I don't see the point of doing it again here.
>  [ Though I will note that no one has argued that my reasons are incorrect or invalid. ]

I think everyone respects your opinion, and there isn't only one right answer here.  I can understand why some vendors would prefer to relegate deprecation notices entirely to release notes, or to make them opt-in.  I can also understand why some users would choose to opt-out of all deprecation notices (e.g., via `-Wno-deprecated`).

As a vendor, we want our users to know immediately about deprecations so that they have maximum time to plan how to update their code.  We want users to be able to suppress deprecation warnings (a) outright, in case they don't want this kind of notice, or (b) temporarily, to avoid noise their builds while they make plans for how to update them.

It's clear that you personally disagree with this policy, and I want to acknowledge that that's a valid opinion.  Nevertheless, given that this policy is fully supported by Clang and we've followed it in Libc++ in the past (e.g., when we added diagnostics to the libstdc++ compatibility headers), it's surprising that you feel so strongly that you might block this entirely, even as a vendor configuration option.

I'm curious, as a thought experiment, let's say you agreed to support vendors that wanted to continue with this policy.  Do you have thoughts on this way of configuring whether vendors adopt it?  Do have you have ideas for different or better opt-out mechanisms (through some combination of `-W` or `-D` flags, or otherwise)?

================
Comment at: libcxx/include/experimental/filesystem:241
+#   if defined(_LIBCPP_WARNING)
+        _LIBCPP_WARNING("std::experimental::filesystem has now been deprecated in favor of C++17's std::filesystem. Please stop using it and start using std::filesystem. This experimental version will be removed in LLVM 11. You can remove this warning by defining the _LIBCPP_NO_EXPERIMENTAL_DEPRECATION_WARNING_FILESYSTEM macro.")
+#   else
----------------
IMO, we should find a way to allow users to opt-out via `-Wno-deprecated`, in addition to (or instead of) macros.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62428/new/

https://reviews.llvm.org/D62428