Re: [PATCH] c++: explicit inst of template method not generated [PR110323]

[Jason Merrill <jason@redhat.com>]

On 3/15/24 13:48, Marek Polacek wrote:
> On Thu, Mar 14, 2024 at 03:39:04PM -0400, Jason Merrill wrote:
>> On 3/8/24 12:02, Marek Polacek wrote:
>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>>>
>>> -- >8 --
>>> Consider
>>>
>>>     constexpr int VAL = 1;
>>>     struct foo {
>>>         template <int B>
>>>         void bar(typename std::conditional<B==VAL, int, float>::type arg) { }
>>>     };
>>>     template void foo::bar<1>(int arg);
>>>
>>> where we since r11-291 fail to emit the code for the explicit
>>> instantiation.  That's because cp_walk_subtrees/TYPENAME_TYPE now
>>> walks TYPE_CONTEXT ('conditional' here) as well, and in a template
>>> finds the B==VAL template argument.  VAL is constexpr, which implies const,
>>> which in the global scope implies static.  constrain_visibility_for_template
>>> then makes "struct conditional<(B == VAL), int, float>" non-TREE_PUBLIC.
>>> Then symtab_node::needed_p checks TREE_PUBLIC, sees it's 0, and we don't
>>> emit any code.
>>>
>>> I thought the fix would be some ODR-esque check to not consider
>>> constexpr variables/fns that are used just for their value.  But
>>> it turned out to be tricky.  For instance, we can't skip
>>> determine_visibility in a template; we can't even skip it for value-dep
>>> expressions.  For example, no-linkage-expr1.C has
>>>
>>>     using P = struct {}*;
>>>     template <int N>
>>>     void f(int(*)[((P)0, N)]) {}
>>>
>>> where ((P)0, N) is value-dep, but N is not relevant here: we have to
>>> ferret out the anonymous type.  When instantiating, it's already gone.
>>
>> Hmm, how is that different from the B == VAL case?  In both cases we're
>> naming an internal entity that gets folded away.
>>
>> I guess the difference is that B == VAL falls under the special allowance in
>> https://eel.is/c++draft/basic.def.odr#14.5.1 because it's a constant used as
>> a prvalue, and therefore is not odr-used under
>> https://eel.is/c++draft/basic.def.odr#5.2
>>
>> So I would limit this change to decl_constant_var_p.  Really we should also
>> be checking that the lvalue-rvalue conversion is applied, but that's more
>> complicated.
> 
> Thanks.  My previous version had it, but it didn't handle
> 
>    static constexpr int getval () { return 1; }
> 
>    template <int B>
>    void baz(typename conditional<B == getval (), int, float>::type arg) { }
> 
> I'd say that "getval()" is one of "manifestly constant-evaluated expressions that
> are not value-dependent", so it should be treated the same as B == VAL.

But it doesn't satisfy the 14.5 rule that corresponding names need to 
refer to the same entity; since getval names a function, it doesn't get 
the special exemption from that rule that VAL gets.

So this should not be treated the same as B == VAL.

> I don't know if this is important to handle.  Do you want me to poke further or
> should we just go with decl_constant_var_p and leave it at that for now?

Just decl_constant_var_p.

Jason