Improve std::source_location::function_name() informativeness

[b1ackviking]

Why does the std::source_location::function_name() return a string equivalent to __builtin_FUNCTION() instead of __FUNCSIG__? Are there any plans to change that in the future?

The <source_location> header was introduced PR #664, and there was a discussion starting from this comment on improving the informativeness of the std::source_location::function_name(). There are also two (1, 2) DevCom tickets that are both in the “Under review” status since August 10, 2021, but there are no feedback since then.

The suggestion is to make the std::source_location::function_name() return the same string as __FUNCSIG__ does, analogous to what GCC and Clang do by returning the string equivalent to __PRETTY_FUNCTION__. Here is the side by side comparison (compiler explorer). Please note, that GCC and Clang also provide the __builtin_FUNCTION() intrinsic which works the same as MSVC implementation, however, libstdc++ and libc++ implementations of source_location rely on the __builtin_source_location() intrinsic which works differently.

This is not a bug report because the current implementation is definitely valid by the C++ Standard, but I find it a significant usability improvement for using source_location, thus bringing it here.

If I am misunderstanding some concepts, please correct me in the comments.

Also tracked by internal VSO-1614161 / AB#1614161 .

[StephanTLavavej]

Internal MSVC-PR-423006 implemented __builtin_FUNCSIG(), which will be available in VS 2022 17.5 Preview 1.

[fsb4000]

@StephanTLavavej , do we need to ask Clang devs and EDG devs to implement __builtin_FUNCSIG() ?

[nuuSolutions]

Why not have both? simple name and full signature
I really liked getting the plain function name without any hassle.

[nuuSolutions]

What is a preprocessor?

[fsb4000]

What is a preprocessor?

A text replacing mechanism which is running before compilation.

More details: https://en.cppreference.com/w/cpp/preprocessor

[jonesmz]

I'm starting to migrate my codebase to using std::source_location over the equivalent home grown type, and I have to say that the switch to __builtin_FUNCSIG() over __builtin_FUNCTION() seems to be a major step backwards in terms of basic readability.

I have an assert macro which, among other things, uses __FUNCTION__ to get the current function name.

With this macro, i get nice, simple, function signatures, for example:

Function: libname::`anonymous-namespace'::parse_fract_time_value

Switching this macro to using std::source_location::current() I get neigh-incomprehensible symbol vomit.

class std::_String_const_iterator<class std::_String_val<struct std::_Simple_types<char> > > __cdecl libname::`anonymous-namespace'::parse_fract_time_value(class std::_String_const_iterator<class std::_String_val<struct std::_Simple_types<char> > >,const class std::_String_const_iterator<class std::_String_val<struct std::_Simple_types<char> > > &,unsigned __int64 *,unsigned __int64 *,unsigned __int64 *)

the actual function signature is

std::string::const_iterator    parse_fract_time_value(std::string::const_iterator         pos, 
                                                   const std::string::const_iterator&  end, 
                                                   std::uint64_t*                        pValue, 
                                                   std::uint64_t*                        pFractNom, 
                                                   std::uint64_t*                        pFractDenom)

Is this really better to have 5x the characters in the output, including the unnecessary class keywords, and fully expanded out template parameters?

C++ has nothing in the standard library to assist developers in parsing function signatures, and MSVC, Clang, and GCC each have their own formatting.

How are we supposed to parse this to get the actual function name?

[SuperWig]

You can define _USE_DETAILED_FUNCTION_NAME_IN_SOURCE_LOCATION to 0 if you want the old behaviour.