Crash when processing user-defined floating point literal with a raw literal operator

[0xjc]

Environment

• OS and Version: Windows 10 Version 22H2
• VS Code Version: 1.78.0-insider (system setup)
• C/C++ Extension Version: v1.15.2 (Pre-Release)
• If using SSH remote, specify OS of remote machine: Ubuntu 22.04.2 LTS

Bug Summary and Steps to Reproduce

Reproduce using the following code:

consteval char operator""_r(const char* p) { return *p; }
void f() { auto x = 1.0_r; }

and hover over the x in the second line. IntelliSense crashes immediately.

Configuration and Logs

Minimal c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Linux",
            "cppStandard": "c++23",
            "compilerPath": "/usr/bin/gcc-12"
        }
    ],
    "version": 4
}

Stack trace from cpptools-srv:

do_constexpr_expression(an_interpreter_state*, an_expr_node*, unsigned char*, unsigned char*) (Unknown Source:0)
do_constexpr_expression(an_interpreter_state*, an_expr_node*, unsigned char*, unsigned char*) (Unknown Source:0)
do_constexpr_statement(an_interpreter_state*, a_statement*) (Unknown Source:0)
do_constexpr_block_statement(an_interpreter_state*, a_statement*, a_scope*) (Unknown Source:0)
do_constexpr_call(an_interpreter_state*, an_expr_node*, unsigned char*, unsigned char*) (Unknown Source:0)
interpret_constexpr_call(an_expr_node*, int, a_constant*, a_diag_list*) (Unknown Source:0)
expr_fold_constexpr_call(an_expr_node*, a_routine**, an_operand*, a_diag_list*) (Unknown Source:0)
make_function_call(an_expr_node*, a_type*, int, int, int, int, int, int, int, int, int, a_source_position*, a_source_position*, a_source_position*, an_operand*, int*, an_expr_node**) (Unknown Source:0)
assemble_function_call(an_operand*, an_operand*, an_expr_node*, int, int, int, int, int, a_source_position*, a_source_position*, a_source_position*, an_operand*, int*, an_expr_node**) (Unknown Source:0)
scan_ud_literal(an_operand*) (Unknown Source:0)
scan_expr_full(an_operand*, an_operand*, int, int) (Unknown Source:0)
scan_expr_as_init_component(int, int) (Unknown Source:0)
prescan_initializer_for_auto_type_deduction(a_decl_parse_state*, int) (Unknown Source:0)
initializer(a_decl_parse_state*, a_source_position*, an_id_linkage_kind, int, int*, a_decl_pos_block*) (Unknown Source:0)
scan_nonmember_declaration(a_decl_parse_state*, a_source_range*) (Unknown Source:0)
decl_statement(int, int*) (Unknown Source:0)
statement(int, int) (Unknown Source:0)
compound_statement_full(int, int, int, int, int, a_type**) (Unknown Source:0)
scan_function_body(a_routine*, a_func_info_block*, unsigned long, a_macro_arg_fixup**, a_macro_arg_fixup**) (Unknown Source:0)
compile_fragment((anonymous namespace)::a_fragment_buffer const&, a_canonicalized_file_name, msvc::strong_typedef_t<msvc::offset_traits>, msvc::strong_typedef_t<msvc::offset_traits>, a_declaration_context const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool, a_region_scope_info const&, msvc::strong_typedef_t<msvc::offset_traits>, bool, bool*, bool, bool, bool) (Unknown Source:0)
before_tu_wrapup() (Unknown Source:0)
process_translation_unit(char const*, int, an_exported_template_file*) (Unknown Source:0)
cfe_main(int, char**) (Unknown Source:0)
cfe_main_exception_handler(int, char**) (Unknown Source:0)
edg_main(int, char**) (Unknown Source:0)
edge_compiler_main(int, char const**) (Unknown Source:0)
preparse(int, char const**, a_scout_store*, edge::translation_unit*) (Unknown Source:0)
a_compiler_thread::compiler_thread_routine(a_compiler_thread*) (Unknown Source:0)
msvc::thread_helper_t::thread_entry(void*) (Unknown Source:0)
libc.so.6!start_thread(void * arg) (pthread_create.c:442)
libc.so.6!clone3() (clone3.S:81)

Other Extensions

No response

Additional context

Standard: lex.ext#4

[sean-mcmanus]

Thanks for reporting this. I've filed internal bug 1803850.

This appears to be an unusual case in which the Linux binary is crashing, but not the Windows binary (they're supposed to be behave the same when configured with the same linux-clang-x64 mode), although it shows "<error-type> x", which is incorrect (msvc mode shows "char x").

[michelleangela]

This is resolved in https://github.com/microsoft/vscode-cpptools/releases/tag/1.16.0.

[michelleangela]

Fix is now available in release version 1.16.2.