On 7/24/25 8:40 AM, Nathaniel Shead wrote:
On Thu, Jul 24, 2025 at 09:02:24PM +1000, Nathaniel Shead wrote:
On Tue, Jul 08, 2025 at 12:51:37PM -0400, Jason Merrill wrote:
I'm resistant to moving functions around unnecessarily, as it makes git
change tracking a lot harder. Especially when it means moving a function to
a file that's already 4x the size of the one you're moving it from.
Instead, I would prefer to add maybe_diagnose_standard_trait to
constraint.cc.
v4 is OK with that adjustment.
Jason
Fair enough, adjusted.
I've been away a few weeks, and there were a number of merge conflicts I
had to resolve first so posting again in case you'd like to re-review
before I submit.
I also ran into an ICE for an adjusted libstdc++ testcase which I added
a testcase for in 'is_destructible3', because it turns out that call
resolution behaves differently with 'complain & tf_error' and will not
always return 'error_mark_node', which comes up with e.g. access
violations.
I suppose this is to enable further diagnostics to occur when not in a
SFINAE context?
Right; if it seems reasonable to continue after an error we often try to
do so to also check later code.
Rather than adjusting call.cc I've adjusted
'is_trivially_xible' and 'is_nothrow_xible' to handle this on that end
instead, let me know if you have any other thoughts here.
@@ -2327,7 +2350,24 @@ constructible_expr (tree to, tree from)
CONSTRUCTOR_IS_PAREN_INIT (from) = true;
expr = perform_direct_initialization_if_possible (to, from,
/*cast*/false,
- tf_none);
+ complain);
+ }
+
+ if (expr == NULL_TREE && explain)
+ {
+ if (len > 1)
+ error ("too many initializers for non-class type %qT", to);
+ else
+ {
+ /* Redo the implicit conversion for diagnostics. */
+ int count = errorcount + warningcount;
+ perform_implicit_conversion_flags (to, orig_from, complain,
+ LOOKUP_NORMAL);
+ if (count == errorcount + warningcount)
+ /* The message may have been suppressed due to -w +
-fpermissive,
+ emit a generic response instead. */
We might suppress -fpermissive here (or higher, perhaps in
diagnose_trait_expr?) for a better diagnostic, since we know we're
already giving an error?
OK either way.
Jason
