AaronBallman wrote:
> > Moving the checks does work for these limited cases, but now that we don't
> > have them there, one of the old tests now doesn't show up the diagnosis:
> > ```c++
> > void f() {
> > throw;
> > }
> >
> > void g() {
> > try {
> > f();
> > } catch (...) {
> > }
> > }
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Since there is a separate call:
> > ```c++
> > return Actions.ActOnCXXTryBlock(TryLoc, TryBlock.get(), Handlers);
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > and debugging under lldb, breakpoints don't reach (i.e exit early) the
> > transform calls.
>
> Right, 'transform' only happens during template instantiation. So we need to
> find 'some place' (that is a seperate function) to do these diagnostics. I
> might suggest doing a new one, since there doesn't seem to be a sensible
> place to do so otherwise... perhaps something like:
>
> ```
> void Sema::DiagnoseExceptionUse(bool isTry) {
> // do the checking + diagnostic here, but have it check the decl-context for
> dependence
> }
> ```
>
> NOTE I had that return `void` instead of `bool`. (And is `Diagnose` instead
> of `Check`). I wonder if there is value to continuing (@AaronBallman??) and
> putting these in the AST anyway? The continued checking is perhaps valuable,
> and tooling might appreciate it in the AST anyway.
Naively, I think `-fno-cxx-exceptions` would mean that `try`, `catch`, and
`throw` are not even keywords; you're opting into a language dialect where
exceptions simply don't exist at all. (`noexcept` is a bit of an outlier, I
think the keyword should still exist, but I think `noexcept(false)` should be a
semantic diagnostic.) However, that's not how Clang or GCC have traditionally
behaved with this option.
GCC's behavior seems to be "if the code is outside of a discarded statement,
then diagnose exception constructs, otherwise do not diagnose exception
constructs but still validate that they're otherwise correct" which... is a
choice: https://godbolt.org/z/36x5qM4dG GCC documents this as a codegen option
so it kind of makes sense from that perspective:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options but
then they diagnose even when codegen is not enabled, which is confusing:
https://godbolt.org/z/fWfzb94e8
Clang's behavior is: "yell, yell loudly, yell as often as you can, don't ever
stop yelling", which is... a worse choice: https://godbolt.org/z/75Y3dMr87
Clang documents this as "enabling C++ exceptions" which is completely vague and
unhelpful:
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fcxx-exceptions
Directly below, we use the same phrasing for
`-fcxx-modules`/`-fno-cxx-modules`, which behaves how I would expect by
disabling the keywords: https://godbolt.org/z/eq4K8E7Mr So our docs are
inconsistent as well as unhelpful. :-/
What are the use cases for disabling exceptions but still allowing the
constructs in source? e.g., do we want to start disabling the keywords
entirely, and thus they won't appear in the AST? Or do we want them to be a
codegen-only option, at which point they do appear in the AST and we only
diagnose at CodeGen time (which is also inconsistent with GCC)? Or do we want
to do whatever GCC does? (Note, Clang has -fcxx-exceptions and GCC does not, so
we're already somewhat inconsistent between the two compilers.)
https://github.com/llvm/llvm-project/pull/139859
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
