emscripten-core / emsdk

Emscripten SDK
http://emscripten.org
Other
3.06k stars 697 forks source link

Regression in 3.1.68 : fmtlib/fmt compilation failure with error : "not a constant expression" #1480

Open ankurvdev opened 1 month ago

ankurvdev commented 1 month ago

"3.1.67" version compiles fine. But "3.1.68" fails to compile fmtlib/fmt library.

The main error seems to be that the iterator arithmetic is not constant expression

'parse_replacement_field<char, fmt::detail::format_string_checker<char, fmt::basic_string_view<char>> &>(&"{}"[1], &"{}"[2], checker(s))'
 2613 |         begin = p = parse_replacement_field(p - 1, end, handler);

Full call log

/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/color.h:473:12: error: call to consteval function 'fmt::basic_format_string<char, fmt::basic_string_view<char>>::basic_format_string<FMT_COMPILE_STRING, 0>' is not a constant expression
  473 |   print(f, FMT_STRING("{}"), string_view(buf.begin(), buf.size()));
      |            ^
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/format.h:1827:23: note: expanded from macro 'FMT_STRING'
 1827 | #define FMT_STRING(s) FMT_STRING_IMPL(s, fmt::detail::compile_string, )
      |                       ^
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/format.h:1806:3: note: expanded from macro 'FMT_STRING_IMPL'
 1806 |   [] {                                                                        \
      |   ^
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/base.h:779:54: note: subexpression not valid in a constant expression
  779 |     format_str_.remove_prefix(detail::to_unsigned(it - begin()));
      |                                                   ~~~^~~~~~~~~
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/base.h:2761:5: note: in call to 'this->context_.advance_to(&"{}"[1])'
 2761 |     context_.advance_to(begin);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/base.h:2756:5: note: in call to 'this->on_format_specs(0, &"{}"[1], &"{}"[1])'
 2756 |     on_format_specs(id, begin, begin);  // Call parse() on empty specs.
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/base.h:2581:5: note: in call to 'handler.on_replacement_field(0, &"{}"[1])'
 2581 |     handler.on_replacement_field(handler.on_arg_id(), begin);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/base.h:2613:21: note: in call to 'parse_replacement_field<char, fmt::detail::format_string_checker<char, fmt::basic_string_view<char>> &>(&"{}"[1], &"{}"[2], checker(s))'
 2613 |         begin = p = parse_replacement_field(p - 1, end, handler);
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/base.h:2884:7: note: in call to 'parse_format_string<true, char, fmt::detail::format_string_checker<char, fmt::basic_string_view<char>>>({&"{}"[0], 2}, checker(s))'
 2884 |       detail::parse_format_string<true>(str_, checker(s));
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ankurv/vcpkg.test/installed/wasm32-emscripten/include/fmt/color.h:473:12: note: in call to 'basic_format_string<FMT_COMPILE_STRING, 0>([] {
    struct __attribute__((visibility("hidden")))  FMT_COMPILE_STRING : fmt::detail::compile_string {
        using char_type [[maybe_unused]] = fmt::remove_cvref_t<decltype("{}"[0])>;
        [[maybe_unused]] constexpr operator fmt::basic_string_view<char_type>() const {
            return fmt::detail_exported::compile_string_to_view<char_type>("{}");
        }
    };
    return FMT_COMPILE_STRING();
}())'
sbc100 commented 1 month ago

This seems likely to be caused by an upstream llvm change.

Perhaps you could help confirm this by bisecting to find the offending change: https://emscripten.org/docs/contributing/developers_guide.html#bisecting

ankurvdev commented 1 month ago

Do you expect it to be the case on all platforms (x64, arm etc) ? Or it could be wasm specific ?

sbc100 commented 1 month ago

Its very unlikely to be wasm specifc since its in the clang/c++ frontend I think? So its likely either a deliberate or accidental regression in clang.