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
