Re: [PATCH] c++: Reject UDLs in certain contexts [PR105300]

[Jason Merrill <jason@redhat.com>]

On 11/16/22 20:12, Marek Polacek wrote:
> 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?

That's what I was thinking.  And the new cp_parser_string_literal could 
also omit the lookup_udlit parm.

> 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.

True, probably better to use that name instead, and rename the current 
one to something like finish_userdef_string_literal

Jason