On Thu, Jul 24, 2025 at 01:16:24PM -0400, Jason Merrill wrote:
> 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
>
Thanks for the idea; I've elected not to suppress it for now because it
could cause confusion if it raises a different error from the actual
error causing the trait to fail in the user's context. I might come
back to this later though, I have a few more changes in this area I'd
like to make.
Nathaniel
