public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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


             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).