P0881 A Proposal to add stacktrace library

[jensmaurer]

P0881R3 A Proposal to add stacktrace library (Alexey Gorgurov, Antony Polukhin)

https://issues.isocpp.org/show_bug.cgi?id=423

[jensmaurer]

CWG in Kona: Defer to LEWG with the following concerns (consensus in CWG):

• Rename stack_frame to invocation_info. (A stack frame would also contain the values of the local variables.)
• Divorce the specification of all invocation_info member functions from the address function, and define a native_handle instead of address (cf. std::thread).
• LEWG should consider the difference between physical and logical invocation records (the latter containing inlined calls, such information possibly obtained from debug info). Consider extending the API to allow to expand physical records to logical records? Was LEWG even aware of the issue when designing the interface?
• Weak feeling: basic_stack_trace might be the wrong name, since stack_frame is the wrong name. Both mention "stack". "stack_trace" does not have strong opposition (as a name) in CWG, but a different / better one would be preferred.
• LEWG should consider making the query functions non-member functions, because they are expensive (similar to the filesystem library, where expensive functions are non-members).

[tituswinters]

LEWG in Kona:

Rename stacktrace to backtrace or back_trace.

Naming for stacktrace:
10 stacktrace
8 backtrace
1 back_trace
1 stack_trace
5 traceback
3 call_stack
4 call_trace
1 call_history

stacktrace vs. backtrace
SS S N B SB
1 4 2 3 3

Naming for stack_frame
2 stack_frame
3 invocation_info
9 stacktrace::entry
3 stacktrace::frame
5 stacktrace_entry
1 stacktrace_frame
2 frame_descriptor
4 call_info
2 call_descriptor
2 frame_info

Prefer stacktraceentry (or backtraceentry).
Nest the stack_frame class inside stacktrace (instead of as a class in std).
SF F N A SA
4 3 1 3 1
(Not consensus, status quo is against, either is OK to get it through CWG).

Leave the expensive operations as member functions.
Unanimous consent

We are OK with the fact that N physical entries can become N+X logical entries after decoding (because of expanding inline functions).
Unanimous consent

Forward back to CWG for C++20.
Unanimous consent

[jensmaurer]

@tituswinters: "We are OK with the fact that N physical entries can become N+X logical entries after decoding": The API as presented doesn't seem to allow that.

[apolukhin]

@tituswinters: "We are OK with the fact that N physical entries can become N+X logical entries after decoding": The API as presented doesn't seem to allow that.

The API has to_string(const stacktrace&) function that does the decoding. It may output N+X lines, while the stacktrace has size() == N. Added a note to wording to describe that behavior.

[wg21bot]

P0881R4 A Proposal to add stacktrace library (Alexey Gorgurov, Antony Polukhin)