Re: [PATCH] c++: resolvedness of resolve_nondeduced_context result [PR126406]

On 7/30/26 10:31 AM, Patrick Palka wrote:
> On Thu, 30 Jul 2026, Jason Merrill wrote:
> 
>> On 7/29/26 3:40 PM, Patrick Palka wrote:
>>> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
>>> OK for trunk/16?
>>>
>>> -- >8 --
>>>
>>> In r16-5967-gbae0ed69e1862a we removed the mark_used logic from
>>> resolve_nondeduced_context under the rationale that it should be the
>>> callers' responsiblity to mark it.  Resolving a template-id overload
>>> shouldn't constitute an ODR-used on its own,
>>
>> Hmm, https://eel.is/c++draft/basic#def.odr-4.1 (plus p8) seems to say it does,
>> as it's the selected member of an overload set in a potentially-evaluated
>> context.
> 
> I see, so resolve_nondeduced_context should call mark_used after all?
> And should it also call mark_used on non-template-id overloads?
> 
>> For r16-5967, I don't see why the patch made a difference to the testcase; in
>> convert_to_void resolve_nondeduced_function is followed by
>> mark_single_function, so we should return error_mark_node regardless of where
>> we first call mark_used.
> 
> The problem is that convert_to_void didn't propagate error_mark_node
> result from mark_used, instead it just returned void_node.  So we could
> have more simply fixed that PR by just propagating error_mark_node
> but I was under the impression that resolve_nondeduced_function shouldn't
> call mark_used at all which incidentally fixes the PR at a higher level
> (resolve_nondeduced_function can no longer return error_mark_node).
> 
>>> and callers would have to
>>> call mark_used anyway to uniformly handle all overloads, including
>>> non-template-id ones.
>>
>> Yes, so r16-5967 is consistent with the comment to mark_single_function.
> 
> But I thought the mentioned [basic.def.odr]/4.1 and /8 suggests
> resolve_nondeduced_function could safely call mark_single_function?

Yes, but the comment to mark_single_function suggests otherwise, and the 
standard_conversion case seems relevant.

Certainly the state before r16-5967 was inconsistent between template 
and non-template cases, and perhaps unconditionally calling 
mark_single_function would help to clarify the cases we need to handle 
differently.

I think maybe we used to mark single non-template functions immediately 
in finish_id_expression, but stopped to avoid duplicate diagnostics?

>>> Removing this logic however now means that resolve_nondeduced_context
>>> could return a specialization whose type is not yet fully resolved
>>> (i.e. has an uninstantiated noexcept or undeduced return type), and
>>> callers that immediately inspect TREE_TYPE of the result (such as
>>> standard_conversion and build_conditional_expr) now misbehave.
>>
>> I think the important case is standard_conversion; at that point we likely
>> haven't finished overload resolution, so the selection is still tentative and
>> so odr-use would be premature.  Though that's why we have tf_conv.  But then,
>> it looks like mark_used wrongly misses resolving auto if tf_conv.
> 
> Yeah, I'm not immediately sure whether tf_conv users expected it resolve
> auto and instaniate noexcept etc.

tf_conv is trying to make sense of a single candidate, which it can't do 
in general without resolving auto.

It shouldn't need to instantiate noexcept unless to match function 
pointer types.

>> In build_conditional_expr it looks like we no longer have anything that will
>> mark_used the resolved operand, i.e. we're missing a call to
>> mark_single_function.  Does this lead to missed instantiation if the return
>> type isn't deduced?
> 
> It causes us to reject the newly added cond2a with:
> 
>    cond2a.C:17:29: error: use of ‘decltype ((b ?  f<int> : <throw-expression>)) g() [with T = int; decltype ((b ?  f<int> : <throw-expression>)) = void (&)()]’ before deduction of ‘auto’
>
> And for
> 
>      bool b;
> 
>      template < class T > void f ()
>      {
>        __builtin_printf("Hello World!\n");
>      }
> 
>      template < class T > void g ()
>      {
>        auto p = !b ? f<int> : throw 0;
>        p();
>      }
> 
>      int main() {
>        g<int>();
>      }
> 
> it seems we eventually call mark_single_function on f<int> from
> cp_build_addr_expr_1, so no missed instantiation in that case at least.

OK, good.  We might add a comment about that after the resolve_.

I guess that also affects the 'addr' case in resolve_nondeduced_context.

>> The function comment for resolve_nondeduced_context should mention that most
>> uses also want mark_single_function.
> 
> They should _eventually_ call mark_single_function, not necessarily
> immediately after, right?

Right.

> For sake of backporting we should we then just revert r16-5967 and
> instead check error_mark_node result from mark_single_function
> in convert_to_void?

Yes, that sounds good for 16.  But it looks like we already do?

Jason