Demo: https://godbolt.org/z/oachhYKcT First reported to https://github.com/fmtlib/fmt/issues/3953. The fmtlib author believes the error below is a compiler bug. Using fmtlib's named arguments inside a generic lambda stopped working as of g++-14.1. The reproducer below compiles on every other compiler I've tried (earlier versions of g++, clang++, intel, and msvc) ``` #include <iostream> #define FMT_HEADER_ONLY #include <fmt/format.h> using namespace fmt::literals; int main() { auto test = [&](auto a) { return fmt::format("{foo} {bar}", "foo"_a="foo", "bar"_a="bar"); }; std::cout << test(1) << std::endl; return 0; } ``` Error: ``` <source>:12:50: error: cannot bind non-const lvalue reference of type 'fmt::v10::detail::named_arg<char, const char (&)[4]>&' to an rvalue of type 'fmt::v10::detail::named_arg<char, const char (&)[4]>' 12 | return fmt::format("{foo} {bar}", "foo"_a="foo", "bar"_a="bar"); | ~~~~~~~^~~~~~ ``` Changing `auto a` to `int a` works around the error. Thank you!
Looks like it started with r14-4111: commit 6e92a6a2a72d3b7a5e1b29042d8a6a43fe1085aa Author: Patrick Palka <ppalka@redhat.com> Date: Mon Sep 18 14:47:52 2023 -0400 c++: non-dependent assignment checking [PR63198, PR18474]
Note lambdas is not need can happen in any template function: ``` #include <iostream> #define FMT_HEADER_ONLY #include <fmt/format.h> using namespace fmt::literals; template<int T> auto test(int a) { return fmt::format("{foo} {bar}", "foo"_a="foo", "bar"_a="bar"); } auto t = test<1>(1); ```
Trying my hand at reducing this slightly.
Reduced testcase: ``` typedef decltype(sizeof(1)) size_t; struct udl_arg { const char *str; template <typename T> auto operator=(T &&value) const -> int {} }; constexpr auto operator""_a(const char *s, size_t) -> udl_arg { return {""}; } template <typename T> void h(T &&); template<int T> int test(int a) { h("t"_a="t"); } auto t = test<1>(1); ````
A bit more reduced, demostrating it's not specific to UDLs: struct udl_arg { udl_arg operator=(int); }; void g(udl_arg&&); template<class T> void h() { udl_arg x; g(x=42); } int main() { h<int>(); }
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:c6cc6d4741a880109c4e0e64d5a189687fb526f6 commit r15-498-gc6cc6d4741a880109c4e0e64d5a189687fb526f6 Author: Patrick Palka <ppalka@redhat.com> Date: Tue May 14 22:55:16 2024 -0400 c++: lvalueness of non-dependent assignment expr [PR114994] r14-4111-g6e92a6a2a72d3b made us check non-dependent simple assignment expressions ahead of time and give them a type, as was already done for compound assignments. Unlike for compound assignments however, if a simple assignment resolves to an operator overload we represent it as a (typed) MODOP_EXPR instead of a CALL_EXPR to the selected overload. (I reckoned this was at worst a pessimization -- we'll just have to repeat overload resolution at instantiatiation time.) But this turns out to break the below testcase ultimately because MODOP_EXPR (of non-reference type) is always treated as an lvalue according to lvalue_kind, which is incorrect for the MODOP_EXPR representing x=42. We can fix this by representing such class assignment expressions as CALL_EXPRs as well, but this turns out to require some tweaking of our -Wparentheses warning logic and may introduce other fallout making it unsuitable for backporting. So this patch instead fixes lvalue_kind to consider the type of a MODOP_EXPR representing a class assignment. PR c++/114994 gcc/cp/ChangeLog: * tree.cc (lvalue_kind) <case MODOP_EXPR>: For a class assignment, consider the result type. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent32.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com>
The releases/gcc-14 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:b3399b445ba7495b0479d43f2389e64d48de870e commit r14-10220-gb3399b445ba7495b0479d43f2389e64d48de870e Author: Patrick Palka <ppalka@redhat.com> Date: Tue May 14 22:55:16 2024 -0400 c++: lvalueness of non-dependent assignment expr [PR114994] r14-4111-g6e92a6a2a72d3b made us check non-dependent simple assignment expressions ahead of time and give them a type, as was already done for compound assignments. Unlike for compound assignments however, if a simple assignment resolves to an operator overload we represent it as a (typed) MODOP_EXPR instead of a CALL_EXPR to the selected overload. (I reckoned this was at worst a pessimization -- we'll just have to repeat overload resolution at instantiatiation time.) But this turns out to break the below testcase ultimately because MODOP_EXPR (of non-reference type) is always treated as an lvalue according to lvalue_kind, which is incorrect for the MODOP_EXPR representing x=42. We can fix this by representing such class assignment expressions as CALL_EXPRs as well, but this turns out to require some tweaking of our -Wparentheses warning logic and may introduce other fallout making it unsuitable for backporting. So this patch instead fixes lvalue_kind to consider the type of a MODOP_EXPR representing a class assignment. PR c++/114994 gcc/cp/ChangeLog: * tree.cc (lvalue_kind) <case MODOP_EXPR>: For a class assignment, consider the result type. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent32.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit c6cc6d4741a880109c4e0e64d5a189687fb526f6)
Fixed for GCC 14.2, thanks for the bug report.