GkvJwa wrote:
> > I think this flew under the radar when this was all getting implemented
> > because we didn't handle async exceptions, so designed the problem away by
> > just turning off EH cleanups if SEH try was used in a function body. I
> > suppose -EHa undoes that logic, bringing this problem back to life.
> > Personally, I don't like the design proposed here of adding a standalone
> > recursive walk of the AST and attempting to pattern match things that might
> > not compile. If the asynch EH numbering algorithm has bugs, I think we'd be
> > better off improving the backend diagnostic to try to make it more
> > actionable to users with LLVM IR debug info. We can leverage the internal /
> > user fatal error distinction and some source locations to emit a more
> > readable error diagnostic and that will help in all cases, instead of
> > having this pattern match that creates additional maintenance and that we
> > can't guarantee fixes all holes in the asynch EH numbering scheme.
>
> This reads similar to what i tried to suggest here: [#172287
> (comment)](https://github.com/llvm/llvm-project/pull/172287#discussion_r2634654818)
>
> In this case we just handle the case for emitting a `seh.scope.begin`, which
> is exactly what we do not handle in the SEH state numbering (only in the CXX
> state numbering).
like this?
```
if (CGF->getLangOpts().EHAsynch && IsEHCleanup && !IsLifetimeMarker &&
CGF->getTarget().getCXXABI().isMicrosoft() && CGF->getInvokeDest()) {
if (const auto *FD = dyn_cast<FunctionDecl>(CGF->CurFuncDecl)) {
if (FD->usesSEHTry()) {
CGF->CGM.getDiags().Report(CGF->CurFuncDecl->getLocation(),
diag::err_seh_expected_handler);
}
}
CGF->EmitSehCppScopeBegin();
}
```
https://github.com/llvm/llvm-project/pull/172287
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
