On Wed, Nov 16, 2022 at 08:22:39AM -0500, Jason Merrill wrote: > On 11/15/22 19:35, Marek Polacek wrote: > > On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote: > > > On 11/12/22 06:53, Marek Polacek wrote: > > > > In this PR, we are crashing because we've encountered a UDL where a > > > > string-literal is expected. This patch makes the parser reject string > > > > and character UDLs in all places where the grammar requires a > > > > string-literal and not a user-defined-string-literal. > > > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > Since the grammar has > > > > > > user-defined-string-literal : > > > string-literal ud-suffix > > > > > > maybe we want to move the UDL handling out to a > > > cp_parser_udl_string_literal > > > that calls cp_parser_string_literal? > > > > Umm, maybe, but the UDL handling code seems to be too entrenched in > > cp_parser_string_literal and I don't think it's going to be easy to extract > > it :/. > > Fair enough; maybe a wrapper, then?
As in, have a cp_parser_udl_string_literal wrapper that calls cp_parser_string_literal with udl_ok=true, rename cp_parser_string_literal, introduce a new cp_parser_string_literal wrapper that passes udl_ok=false? One problem with cp_parser_udl_string_literal is that it's too similar to cp_parser_userdef_string_literal, which would be confusing, I think. Marek
