On 2/19/26 10:35 PM, Marek Polacek wrote:
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.
That still sounds more localized, and therefore better, than cluttering
the API with more splice_p parameters.
Jason
