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).

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

@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.

@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.

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

P0881R5 A Proposal to add stacktrace library (Antony Polukhin, Antony Polukhin)

This was not adopted for C++20. Removing the "C++20" label.

@jensmaurer is the core label still relevant here? My understanding is that we are down to lwg now?

@JeffGarland: Correct, CWG is done with it. Is LWG going to move it? Otherwise, we should keep the CWG label.

I can't say when, but trying to triage our queue and presumed this would be on it since it dropped due to time. I thought normally when CWG was done that tag gets removed, so didn't want to put it on our list if CWG was still doing something. Thanks.

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

Catching up the status here -- LWG did an initial review of this which has lead to the R6 updates.

https://wiki.edg.com/bin/view/Wg21summer2020/P0881R5:Stack_trace

LWG has completed further reviews on 9/04

https://wiki.edg.com/bin/view/Wg21summer2020/Telecon-20200904

and a final review on 9/11
https://wiki.edg.com/bin/view/Wg21summer2020/Telecon-20200911

--> with a vote to move into c++23 working paper

Everybody in favor of moving P0881R7 into the C++23 working paper

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

Adopted 2020-11.