On 4/29/21 3:22 PM, Edward Catmur wrote:
> On Thu, 29 Apr 2021 at 13:16, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto: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]>
> <mailto: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.

Presumably, someone has to tell the runtime to collect the stacktrace,
and, if I understood you right, that someone is supposed to be the
compiler, which sees a std::current_exception_stacktrace call in the
catch block.

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

I don't see how you arrive to this conclusion. And a catch handler
absolutely will contain a call to a different TU, even if to merely log
the event.