From: Jonathan Wakely <jwakely@redhat.com>
To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: [PATCH] libstdc++: Better diagnostics for std::format errors
Date: Fri, 1 Mar 2024 14:44:30 +0000 [thread overview]
Message-ID: <20240301150812.95213-1-jwakely@redhat.com> (raw)
Does the text of these new diagnostics look good?
There are of course other ways for a type to be not-formattable (e.g.
the formatter::format member doesn't return the right type or has some
other kind of incorrect signature, or the formatter::parse member isn't
constexpr) but we can't predict/detect them all reliably. This just
attempts to give a user-friendly explanation for a couple of common
mistakes. It should not have any false positives, because the
basic_format_arg constructor requires __formattable_with<_Tp, _Context>
so if either of these assertions fails, constructing __arg will fail
too. The static_assert only adds a more readable error for a
compilation that's going to fail anyway.
Tested x86_64-linux.
-- >8 --
This adds two new static_assert messages to the internals of
std::make_format_args to give better diagnostics for invalid format
args. Rather than just getting an error saying that basic_format_arg
cannot be constructed, we get more specific errors for the cases where
std::formatter isn't specialized for the type at all, and where it's
specialized but only meets the BasicFormatter requirements and so can
only format non-const arguments.
Also add a test for the existing static_assert when constructing a
format_string for non-formattable args.
libstdc++-v3/ChangeLog:
* include/std/format (_Arg_store::_S_make_elt): Add two
static_assert checks to give more user-friendly error messages.
* testsuite/lib/prune.exp (libstdc++-dg-prune): Prune another
form of "in requirements with" note.
* testsuite/std/format/arguments/args_neg.cc: Check for
user-friendly diagnostics for non-formattable types.
* testsuite/std/format/string_neg.cc: Likewise.
---
libstdc++-v3/include/std/format | 13 +++++++
libstdc++-v3/testsuite/lib/prune.exp | 1 +
.../std/format/arguments/args_neg.cc | 34 ++++++++++++++++++-
.../testsuite/std/format/string_neg.cc | 4 +++
4 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index ee189f9086c..1e839e88db4 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -3704,6 +3704,19 @@ namespace __format
static _Element_t
_S_make_elt(_Tp& __v)
{
+ using _Tq = remove_const_t<_Tp>;
+ using _CharT = typename _Context::char_type;
+ static_assert(is_default_constructible_v<formatter<_Tq, _CharT>>,
+ "std::formatter must be specialized for the type "
+ "of each format arg");
+ using __format::__formattable_with;
+ if constexpr (is_const_v<_Tp>)
+ if constexpr (!__formattable_with<_Tp, _Context>)
+ if constexpr (__formattable_with<_Tq, _Context>)
+ static_assert(__formattable_with<_Tp, _Context>,
+ "format arg must be non-const because its "
+ "std::formatter specialization has a "
+ "non-const reference parameter");
basic_format_arg<_Context> __arg(__v);
if constexpr (_S_values_only)
return __arg._M_val;
diff --git a/libstdc++-v3/testsuite/lib/prune.exp b/libstdc++-v3/testsuite/lib/prune.exp
index 24a15ccad22..071dcf34c1e 100644
--- a/libstdc++-v3/testsuite/lib/prune.exp
+++ b/libstdc++-v3/testsuite/lib/prune.exp
@@ -54,6 +54,7 @@ proc libstdc++-dg-prune { system text } {
regsub -all "(^|\n)\[^\n\]*: . skipping \[0-9\]* instantiation contexts \[^\n\]*" $text "" text
regsub -all "(^|\n)\[^\n\]*: in .constexpr. expansion \[^\n\]*" $text "" text
regsub -all "(^|\n)\[^\n\]*: in requirements .with\[^\n\]*" $text "" text
+ regsub -all "(^|\n)\[^\n\]*: in requirements with\[^\n\]*" $text "" text
regsub -all "(^|\n) inlined from \[^\n\]*" $text "" text
# Why doesn't GCC need these to strip header context?
regsub -all "(^|\n)In file included from \[^\n\]*" $text "" text
diff --git a/libstdc++-v3/testsuite/std/format/arguments/args_neg.cc b/libstdc++-v3/testsuite/std/format/arguments/args_neg.cc
index 16ac3040146..ded56fe63ab 100644
--- a/libstdc++-v3/testsuite/std/format/arguments/args_neg.cc
+++ b/libstdc++-v3/testsuite/std/format/arguments/args_neg.cc
@@ -6,7 +6,39 @@
std::string rval() { return "path/etic/experience"; }
-void f()
+void test_rval()
{
(void)std::make_format_args(rval()); // { dg-error "cannot bind non-const lvalue reference" }
}
+
+void test_missing_specialization()
+{
+ struct X { };
+ X x;
+ (void)std::make_format_args(x); // { dg-error "here" }
+// { dg-error "std::formatter must be specialized" "" { target *-*-* } 0 }
+}
+
+struct Y { };
+template<> class std::formatter<Y> {
+public:
+ constexpr typename format_parse_context::iterator
+ parse(format_parse_context& c)
+ { return c.begin(); }
+
+ template<class C>
+ typename C::iterator format(Y&, C&) const;
+};
+
+void test(std::formatter<Y>& f, std::format_parse_context& pc) {
+ f.parse(pc);
+}
+
+void test_const_arg()
+{
+ const Y y;
+ (void)std::make_format_args(y); // { dg-error "here" }
+// { dg-error "format arg must be non-const" "" { target *-*-* } 0 }
+}
+
+// { dg-prune-output "no matching function for call to .*::basic_format_arg<" }
diff --git a/libstdc++-v3/testsuite/std/format/string_neg.cc b/libstdc++-v3/testsuite/std/format/string_neg.cc
index 69bcc736cff..d5963145b18 100644
--- a/libstdc++-v3/testsuite/std/format/string_neg.cc
+++ b/libstdc++-v3/testsuite/std/format/string_neg.cc
@@ -4,3 +4,7 @@
auto s = std::format(" {9} "); // { dg-error "call to consteval function" }
// { dg-error "invalid.arg.id" "" { target *-*-* } 0 }
+
+struct X { };
+std::format_string<X> str(""); // dg-error "here" }
+// { dg-error "std::formatter must be specialized" "" { target *-*-* } 0 }
--
2.43.2
next reply other threads:[~2024-03-01 15:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 14:44 Jonathan Wakely [this message]
2024-03-07 20:59 ` Jonathan Wakely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240301150812.95213-1-jwakely@redhat.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).