ICE on the testcase error9.C below when using
instantiate_decl here, since we indeed end up calling it for the
non-specialization f(bool).
Does the following look OK?
-- >8 --
Subject: [PATCH] c++: Fix resolving the address of overloaded pmf [PR96647]
In resolve_address_of_overloaded_funct
unk? This looks like it
> could call instantiate_decl for a non-template function, which is wrong.
Good point. We even ICE on the testcase error9.C below when using
instantiate_decl here, since we indeed end up calling it for the
non-specialization f(bool).
Does the following look OK?
-- >
On 8/28/20 12:45 PM, Patrick Palka wrote:
(Removing libstd...@gcc.gnu.org from CC list)
On Fri, 28 Aug 2020, Patrick Palka wrote:
In resolve_address_of_overloaded_function, currently only the second
pass over the overload set (which considers just the function templates
in the overload set) che
(Removing libstd...@gcc.gnu.org from CC list)
On Fri, 28 Aug 2020, Patrick Palka wrote:
> In resolve_address_of_overloaded_function, currently only the second
> pass over the overload set (which considers just the function templates
> in the overload set) checks constraints and performs return typ
In resolve_address_of_overloaded_function, currently only the second
pass over the overload set (which considers just the function templates
in the overload set) checks constraints and performs return type
deduction when necessary. But as the testcases below show, we need to
do this when consideri
