On Thu, 29 Apr 2021 at 13:16, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 4/29/21 2:38 PM, Edward Catmur wrote:
> > On Thu, 29 Apr 2021 at 12:22, Andrey Semashev via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
> >
> > On 4/29/21 1:13 PM, Edward Catmur wrote:
> > > If you're using exceptions for control flow the compiler will be
> > able to
> > > see the whole of the program accessible from the catch block.
> >
> > I don't see how.
> >
> > Presumably your catch block is empty in that case?
>
> I'm sorry, you completely lost me. How a catch block is empty and yet it
> contains std::current_exception_stacktrace call and supposedly processes
> (logs?) a stacktrace?
>
> My point is that the throw site, the catch site and
> std::current_exception_stacktrace call site can all be in different TUs,
> and the compiler cannot see all of them at once. So
> std::current_exception_stacktrace call cannot be an indication that a
> stacktrace needs to be collected at the throw site.
>

The TU of the throw site is irrelevant; collecting the stack trace during
unwinding is performed by the runtime, not by the throwing code.

If the catch site calls outside its own TU then yes, the compiler should
assume that it may access the exception stack trace. But if it's being used
for control flow then it won't call outside its own TU since the exception
is expected.