On Thu, Feb 19, 2026 at 05:28:24PM +0900, Jason Merrill wrote: > On 2/12/26 12:29 AM, Marek Polacek wrote: > > On Wed, Feb 11, 2026 at 05:02:40PM +0900, Jason Merrill wrote: > > > On 2/11/26 1:05 AM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > -- >8 -- > > > > In <https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705175.html> > > > > (bottom of the message) we discussed not passing ctx to > > > > finish_id_expression > > > > so that we can get rid of the _deferring_access_checks calls. So the > > > > cp_parser_splice_expression changes are what we want. In order to be > > > > able to do that, I had to adjust finish_id_expression_1 so that things > > > > like &[: ^^S::fn :] and &[: ^^S::mem :] keep working. > > > > > > Would it make sense to call build_offset_ref in > > > cp_parser_splice_expression? > > > > I could do that, but then I'd also have to duplicate the calls to > > push/pop_deferring_access_checks, and add checks around build_offset_ref > > just like in the r16-7445 patch. But then I think I wouldn't have > > to add the new splice_p parameter. Thought maybe we want to signal to > > finish_class_member_access_expr that we're coming from a splice anyway. > > But why? I would think that accessing a pre-determined member ought to work > the same whether or not it comes from a splice.
I don't think passing splice_p to finish_class_member_access_expr currently does anything. But the note about various checks that would have to be added around build_offset_ref still stands. Marek
