Re: [PATCH] c++: implicitly_declare_fn and access checks [PR113908]

[Jason Merrill <jason@redhat.com>]

On 2/13/24 11:49, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, are one of
> both of these fixes OK for trunk?
> 
> -- >8 --
> 
> Here during ahead of time checking of the non-dependent new-expr we
> synthesize B's copy constructor, which should be defined as deleted
> due to A's inaccessible copy constructor.  But enforce_access incorrectly
> decides to defer the (silent) access check for A::A(const A&) during
> synthesization since current_template_parms is still set (before r14-557
> it checked processing_template_decl which got cleared from
> implicitly_declare_fn), which leads to the access check leaking out to
> the template context that needed the synthesization.
> 
> This patch narrowly fixes this regression in two sufficient ways:
> 
> 1. Clear current_template_parms alongside processing_template_decl
>     in implicitly_declare_fn so that it's more independent of context.

Hmm, perhaps it or synthesized_method_walk should use 
maybe_push_to_top_level?

> 2. Don't defer a silent access check when in a template context,
>     since such deferred checks will be replayed noisily at instantiation
>     time which may not be what the caller intended.

True, but returning a possibly incorrect 'false' is probably also not 
what the caller intended.  It would be better to see that we never call 
enforce_access with tf_none in a template.  If that's not feasible, I 
think we should still conservatively return true.

Jason