clang-diagnostic-error for boost include

[chrchr-github]

#include <boost/date_time/posix_time/posix_time.hpp>

After upgrading from clang19 to clang20-rc1, the line above causes this error:

boost/boost_1_73_0\boost/mpl/aux_/integral_wrapper.hpp:73:31: error: non-type template argument is not a constant expression [clang-diagnostic-error]
   73 |     typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;
      |                               ^
boost/boost_1_73_0\boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
   24 | #   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
      |                                               ^
<snip>

This happens on Windows, but I don't see it here for some reason: https://godbolt.org/z/ooEnPzWqW

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (chrchr-github)

~~~c++ #include <boost/date_time/posix_time/posix_time.hpp> ~~~

After upgrading from clang19 to clang20-rc1, the line above causes this error:

boost/boost_1_73_0\boost/mpl/aux_/integral_wrapper.hpp:73:31: error: non-type template argument is not a constant expression [clang-diagnostic-error]
   73 |     typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;
      |                               ^
boost/boost_1_73_0\boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
   24 | #   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
      |                                               ^
<snip>

This happens on Windows, but I don't see it here for some reason: https://godbolt.org/z/ooEnPzWqW

[shafik]

CC @AaronBallman

[AaronBallman]

Thanks for the report! A few questions:

Do you get the same diagnostic from clang, or only from clang-tidy?

Can you provide the output from -E or -save-temps?

[chrchr-github]

Do you get the same diagnostic from clang, or only from clang-tidy?

clang and clang-tidy are both affected.

Can you provide the output from -E or -save-temps?

Please see the attachment.

E.zip

[AaronBallman]

Thank you for this! I was able to reproduce locally, and I think this is actually a bug with boost, but I'm not yet 100% certain. A critical note was snipped from the original message (which is understandable, there's a ton of notes thanks to the instantiation stack):

C:\Users\aballman\OneDrive - Intel Corporation\Desktop\E\E.cpp:58615:28: note: integer value -1 is outside the valid
      range of values [0, 3] for the enumeration type 'int_float_mixture_enum'
 58615 |     typedef integral_c< T, static_cast<T>((value - 1)) > prior;

which corresponds to:

llvm-project/clang/docs/ReleaseNotes.rst

Line 109 in c08c9f9

- Clang will now correctly diagnose as ill-formed a constant expression where an

[chrchr-github]

Thanks for the quick diagnosis. I have verified that the error does not occur with boost 1.80 or later (versions up to 1.79 are affected).
Maybe I'll just have to upgrade.

[AaronBallman]

I've verified, the issue is with out-of-bounds enumeration values, so closing this as not a bug. Glad to hear the issue is resolved in 1.80!

[chrchr-github]

But this also means that anyone with a dependency on boost < 1.80 will not be able to use clang20 right away. Is there a policy for this type of situation?

[AaronBallman]

But this also means that anyone with a dependency on boost < 1.80 will not be able to use clang20 right away. Is there a policy for this type of situation?

Users will have to either upgrade their boost version to one which is not broken, carry local patches to boost which address the issue, or continue with Clang 19 and using -Wno-error=enum-constexpr-conversion. (We gave a ~2 year window for projects to update their code, this was being diagnosed as an error by default since Clang 16:

llvm-project/clang/docs/ReleaseNotes.rst

Line 170 in 7cbf1a2

- Clang will now correctly diagnose as ill-formed a constant expression where an

)

[chrchr-github]

This should be a reproducer:

enum E { E0 };

template<E e>
struct S {};

typedef S<static_cast<E>(-1)> T;

Compilation has indeed failed since clang16, and the error has merely become non-suppressible with clang20.

The odd thing is, I can't see any -Wno-error=enum-constexpr-conversion, which would have enabled compilation of our project so far. Can this be injected somehow?

Relevant:
#59036
boostorg/mpl#69

<source>:6:11: note: integer value -1 is outside the valid range of values [0, 1] for the enumeration type 'E'
The range of values seems to be that of a hypothetical bitfield that the compiler could use to represent the enumerator values. So compilation will succeed for e.g. enum E : int { E0 };

[AaronBallman]

The odd thing is, I can't see any -Wno-error=enum-constexpr-conversion, which would have enabled compilation of our project so far. Can this be injected somehow?

I'm not certain I understand, here's an example of that in practice: https://godbolt.org/z/vPsrhv5Ta

:6:11: note: integer value -1 is outside the valid range of values [0, 1] for the enumeration type 'E' The range of values seems to be that of a hypothetical bitfield that the compiler could use to represent the enumerator values.

Correct, that's this bit of the C++ standard: https://eel.is/c++draft/enum#dcl.enum-8

So compilation will succeed for e.g. enum E : int { E0 };

Correct, that makes an unscoped enumeration with a fixed underlying type of int.

[chrchr-github]

The odd thing is, I can't see any -Wno-error=enum-constexpr-conversion, which would have enabled compilation of our project so far. Can this be injected somehow?

I'm not certain I understand, here's an example of that in practice: https://godbolt.org/z/vPsrhv5Ta

Well, if the code is rejected since clang16 unless there was -Wno-error=enum-constexpr-conversion, I would have expected to find that somewhere, since compilation works with clang19. Apparently, a #pragma could also be used to suppress the error. But maybe I wasn't looking in the right place.

[AaronBallman]

The odd thing is, I can't see any -Wno-error=enum-constexpr-conversion, which would have enabled compilation of our project so far. Can this be injected somehow?

I'm not certain I understand, here's an example of that in practice: https://godbolt.org/z/vPsrhv5Ta

Well, if the code is rejected since clang16 unless there was -Wno-error=enum-constexpr-conversion, I would have expected to find that somewhere, since compilation works with clang19. Apparently, a #pragma could also be used to suppress the error. But maybe I wasn't looking in the right place.

Ah, I see, thanks! I'm not certain why you're not seeing the issue. It could be suppressed via a #pragma (or _Pragma), -Wno-enum-constexpr-conversion, -Wno-error=enum-constexpr-conversion, -Wno-everything, and I'm probably forgetting some others.