Bug 105300

Is it really a valid code since clang rejects it?

$ clang++ pr105300.C -c
pr105300.C:2:27: error: string literal with user-defined suffix cannot be used here
static_assert(false, "foo"_x);
                          ^
1 error generated.

MSVC produces a decent error message:

<source>(2): error C3690: expected a string literal, but found a user-defined string literal instead

Note best definition of the operator is just:
void operator""_x(const char *, decltype(sizeof(0)));
static_assert(false, "foo"_x);


Oh we started to ICE between GCC 5 and 6. Most likely when we started to print out the message too.

Something like:
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 7c5f90b5127..185e0ac53f7 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -11203,6 +11203,13 @@ finish_static_assert (tree condition, tree message, location_t location,
   if (check_for_bare_parameter_packs (condition))
     condition = error_mark_node;

+  if (TREE_CODE (message) != STRING_CST)
+    {
+      location_t mloc = cp_expr_loc_or_loc (message, location);
+      error_at (mloc, "user defined suffix not expected here");
+      return;
+    }
+
   if (instantiation_dependent_expression_p (condition))
     {
       /* We're in a template; build a STATIC_ASSERT and put it in


Should fix this I think ....

We also crash on

  asm (""_x);

but not

extern ""_x { void g(); }

A more complete test:

// PR c++/105300

void operator""_x(const char *, decltype(sizeof(0)));
static_assert(false, "foo"_x);

extern ""_x { void g(); }

void
lol ()
{
  asm (""_x);
}

The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:9f353b0c1dc9385ba8b8a64b65d66d5452383c11

commit r13-5390-g9f353b0c1dc9385ba8b8a64b65d66d5452383c11
Author: Marek Polacek <polacek@redhat.com>
Date:   Fri Nov 11 17:59:30 2022 -0500

    c++: Reject UDLs in certain contexts [PR105300]
    
    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.
    
    I've introduced two new wrappers; the existing cp_parser_string_literal
    was renamed to cp_parser_string_literal_common and should not be called
    directly.  finish_userdef_string_literal is renamed from
    cp_parser_userdef_string_literal.
    
            PR c++/105300
    
    gcc/c-family/ChangeLog:
    
            * c-pragma.cc (handle_pragma_message): Warn for CPP_STRING_USERDEF.
    
    gcc/cp/ChangeLog:
    
            * parser.cc: Remove unnecessary forward declarations.
            (cp_parser_string_literal): New wrapper.
            (cp_parser_string_literal_common): Renamed from
            cp_parser_string_literal.  Add a bool parameter.  Give an error when
            UDLs are not permitted.
            (cp_parser_userdef_string_literal): New wrapper.
            (finish_userdef_string_literal): Renamed from
            cp_parser_userdef_string_literal.
            (cp_parser_primary_expression): Call cp_parser_userdef_string_literal
            instead of cp_parser_string_literal.
            (cp_parser_linkage_specification): Move a variable declaration closer
            to its first use.
            (cp_parser_static_assert): Likewise.
            (cp_parser_operator): Call cp_parser_userdef_string_literal instead of
            cp_parser_string_literal.
            (cp_parser_asm_definition): Move a variable declaration closer to its
            first use.
            (cp_parser_asm_specification_opt): Move variable declarations closer to
            their first use.
            (cp_parser_asm_operand_list): Likewise.
            (cp_parser_asm_clobber_list): Likewise.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/cpp0x/udlit-error1.C: New test.

Fixed for GCC 13.  I don't think I want to backport the patch.

*** Bug 109459 has been marked as a duplicate of this bug. ***