Skip to content

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

Open

Description

@ankurvdev

"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();
}())'

Activity

  1. sbc100 commented on Oct 25, 2024

    @sbc100
    Collaborator

    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

  2. ankurvdev commented on Oct 25, 2024

    @ankurvdev
    Author

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

  3. sbc100 commented on Oct 25, 2024

    @sbc100
    Collaborator

    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.

  4. sbc100 commented on Aug 5, 2026

    @sbc100
    Collaborator

    I assume this is now longer and issue? OK to close this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions