[cfe-dev] Improving diagnostics when moving standard library headers

Richard Powell via cfe-dev cfe-dev at lists.llvm.org
Thu Aug 9 08:25:01 PDT 2018


At least at a minimum could we have <experimental/optional> be:

#ifdef __USE_STD_OPTIONAL
#include <optional>
#else
#error "<experimental/optional> has been removed. Use <optional> instead."
#endif

That way we can have <experimental/optional> for application users to move over to <optional>, but have library writers have a way to provide “backward” compatible libraries (ie, libraries that need to work on systems that do not yet have <optional>, where checking then using <experimental/optional> is a legit operation)?

Richard

> On Aug 9, 2018, at 8:13 AM, Louis Dionne <ldionne at apple.com> wrote:
> 
> Hi,
> 
> In libc++, we moved the <experimental/optional> header to <optional>. To guide users when they try to use <experimental/optional>, that file now contains:
> 
>    #error "<experimental/optional> has been removed. Use <optional> instead."
> 
> The problem is that it traps people using __has_include(<experimental/optional>) to detect whether they should be using std::experimental::optional or std::optional on the version of the standard library they're using. For example:
> 
>    #if __has_include(<experimental/optional>)
>    #   include <experimental/optional>
>    #else
>    #   include <optional>
>    #endif
> 
> This is currently always broken, since <experimental/optional> is always provided, but including it is an error.
> 
> I believe a better situation would be to remove the header, but somehow have a way of providing a better compiler diagnostic than the default one when that header is included. The default diagnostic will just say “I can’t find this header!”, whereas we really want to say "This header has been moved over there". Ideally, this sort of feature would also be usable by other libraries, not just the standard library, but I’d welcome just about any solution for now.
> 
> My question: Do we have a way of achieving what I'm requesting today? If not, does anyone have ideas about how to achieve this? My guess is that a pragma in the header that's been moved would not work, because that means __has_include would have to know way more than it probably does today.
> 
> Thanks,
> Louis
> 




More information about the cfe-dev mailing list