What is the guideline when encountering ICE?

[patrickroberts]

See instances of // ICE in tests/beman/any_view/constexpr.test.cpp for reference.

For now, I've disabled the static_assert tests that cause an ICE on GCC or MSVC, and only for the specific compilers that error. As was my experience with my previous implementation of any_view, combining dynamic allocation, type-erasure, and constant evaluation generally tends to cause issues for compilers, and while this is not entirely surprising, it poses the question of what to do from here.

I don't mind filing bug reports with GCC and MSVC, but given that constexpr support for any_view isn't currently on track for standardization as of P3411R1, I don't want these bug reports to be potentially perceived as useless or wasteful of others' time, especially while representing the Beman Project.

Does anyone else have any opinions on this topic they'd like to share?

[ednolan]

I don't want these bug reports to be potentially perceived as useless or wasteful of others' time

If the report you file is for a genuine bug and it has a minimal reproduction, I wouldn't think that it would be perceived that way.

I've filed many compiler bug reports in the process of developing beman.utf_view and I never worried that my bug reporting was excessive.

For now, I've disabled the static_assert tests that cause an ICE on GCC or MSVC, and only for the specific compilers that error.

This seems like the correct approach to me. In utf_view, I encountered so many constexpr issues with MSVC that I just took the approach of turning off constexpr support with macros if I detect that compiler: https://github.com/bemanproject/utf_view/blob/main/include/beman/utf_view/detail/constexpr_unless_msvc.hpp

Note that the header file above contains links to three bug reports I filed against MSVC for constexpr issues.