On Thu, Mar 14, 2019 at 04:22:41PM -0400, Jason Merrill wrote:
> On 3/7/19 4:52 PM, Marek Polacek wrote:
> > This was one of those PRs where the more you poke, the more ICEs turn up.
> > This patch fixes the ones I could find. The original problem was that
> > maybe_instantiate_noexcept got a TEMPLATE_DECL created for the member
> > friend template in do_friend. Its noexcept-specification was deferred,
> > so we went to the block with push_access_scope, but that crashes on a
> > TEMPLATE_DECL. One approach could be to somehow not defer noexcept-specs
> > for friend templates, I guess, but I didn't want to do that.
>
> How does it make sense to instantiate the noexcept-specifier of a template?
> We should only get there for fully-instantiated function decls.
Hmm, but duplicate_decls calls check_redeclaration_exception_specification even
for DECL_FUNCTION_TEMPLATE_Ps.
It's likely I got this wrong, but I thought template friends are somewhat
special, and they are wrapped in a TEMPLATE_DECL even when it's not an
instantiation. If I have this
template <typename>
class C {
int n;
template <int N>
friend int foo(C);
};
template <int N>
int foo(C<int> c)
{
return c.n;
}
void
g ()
{
C<int> c;
foo<0>(c);
}
then we call instantiate_class_template for C, which calls
tsubst_friend_function
on the TEMPLATE_DECL foo, but that remains a TEMPLATE_DECL, unlike for member
template functions. Here's a related patch:
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01918.html
Note the crash happens in tsubst_friend_function. I wouldn't know when to
check the noexcept-specifier of such a TEMPLATE_DECL for a template friend
if not there.
> > Lastly, I found an invalid testcase that was breaking because a template
> > code
> > leaked to constexpr functions. This I fixed similarly to the recent
> > explicit
> > PR fix (r269131).
>
> This spot should probably also use build_converted_constant_expr.
Ok, I'll address this.
Marek
