Re: [PATCH] c++: Don't require accessible dtors for some forms of new [PR59238]

2020-12-08 Thread Jason Merrill via Gcc-patches
On 12/8/20 5:57 PM, Jakub Jelinek wrote: On Tue, Dec 08, 2020 at 05:34:13PM -0500, Jason Merrill wrote: On 12/8/20 4:23 AM, Jakub Jelinek wrote: The earlier cases in build_new_1 already use | tf_no_cleanup, these are cases where the type isn't type_build_ctor_call nor explicit_value_init_p. It

Re: [PATCH] c++: Don't require accessible dtors for some forms of new [PR59238]

2020-12-08 Thread Jakub Jelinek via Gcc-patches
On Tue, Dec 08, 2020 at 05:34:13PM -0500, Jason Merrill wrote: > On 12/8/20 4:23 AM, Jakub Jelinek wrote: > > The earlier cases in build_new_1 already use | tf_no_cleanup, these are > > cases where the type isn't type_build_ctor_call nor explicit_value_init_p. > > It is true that often one can't de

Re: [PATCH] c++: Don't require accessible dtors for some forms of new [PR59238]

2020-12-08 Thread Jason Merrill via Gcc-patches
On 12/8/20 4:23 AM, Jakub Jelinek wrote: Hi! The earlier cases in build_new_1 already use | tf_no_cleanup, these are cases where the type isn't type_build_ctor_call nor explicit_value_init_p. It is true that often one can't delete these (unless e.g. the dtor would be private or protected and del

[PATCH] c++: Don't require accessible dtors for some forms of new [PR59238]

2020-12-08 Thread Jakub Jelinek via Gcc-patches
Hi! The earlier cases in build_new_1 already use | tf_no_cleanup, these are cases where the type isn't type_build_ctor_call nor explicit_value_init_p. It is true that often one can't delete these (unless e.g. the dtor would be private or protected and deletion done in some method), but diagnosing