On 2/20/26 1:14 AM, Marek Polacek wrote:
On Thu, Feb 19, 2026 at 11:07:56PM +0900, Jason Merrill wrote:
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.
Ok, fair enough. How about this, then?
+ else if (VAR_P (t) && DECL_CLASS_SCOPE_P (t))
+ /* finish_id_expression doesn't handle these well:
+ constexpr auto r = ^^S::i;
+ auto a = [:r:]; */
This seems to be referring to this assert in finish_id_expression_1:
/* PATH can be null for using an enum of an unrelated
class; we checked its access in lookup_using_decl.
??? Should this case make a clone instead, like
handle_using_decl? */
gcc_assert (TREE_CODE (decl) == CONST_DECL);
How about, instead of a special case in cp_parser_splice_expression,
adding || flag_reflection to the assert?
Jason
