[PATCH] D138958: [clang] Better UX for Clang’s unwind-affecting attributes

Aaron Ballman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 10 12:57:23 PST 2023


aaron.ballman added inline comments.


================
Comment at: clang/include/clang/Basic/Attr.td:4133
+def NoUnwind : DeclOrStmtAttr {
+  let Spellings = [Clang<"nounwind", /*allowInC =*/0>];
+  let Accessors = [Accessor<"isClangNoUnwind", [CXX11<"clang", "nounwind">]>];
----------------
lebedev.ri wrote:
> aaron.ballman wrote:
> > Should this be allowed in C (where structured exception handling is still a thing)?
> The only two thing about structured exceptions i know
> is that it's abbreviation and that it's a MSVC thing. 
> I don't know anything about how "exceptions" work there,
> and therefore i do not want to touch it.
> 
> https://llvm.org/docs/LangRef.html notes:
> ```
> nounwind
> This function attribute indicates that the function never raises an exception. <...>.
> However, functions marked nounwind may still trap or generate asynchronous exceptions.
> Exception handling schemes that are recognized by LLVM to handle asynchronous exceptions,
> such as SEH, will still provide their implementation defined semantics.
> ```
Okay, let's leave it as-is for now and we can relax the restriction later if we find a need.


================
Comment at: clang/include/clang/Basic/Attr.td:4138
+                             "functions and statements">;
+  let SimpleHandler = 1;
+}
----------------
lebedev.ri wrote:
> aaron.ballman wrote:
> > I would have guessed we'd want to help the user out in a case like: `[[clang::nounwind]] void func() noexcept(false);`, given that this stuff can creep in via macros?
> Could you please clarify, what do you mean by "help the user" in this case?
> Given
> ```
> [[clang::nounwind]] void func() noexcept(false);
> 
> void qqq();
> 
> void foo() {
>   try {
>     func();
>   } catch (...) {
>     qqq();
>   }
> }
> ```
> we already end up with
> ```
> ; Function Attrs: mustprogress noinline nounwind optnone uwtable
> define dso_local void @_Z3foov() #0 {
> entry:
>   call void @_Z4funcv() #2
>   ret void
> }
> 
> ; Function Attrs: nounwind
> declare void @_Z4funcv() #1
> 
> attributes #0 = { mustprogress noinline nounwind optnone uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
> attributes #1 = { nounwind "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
> attributes #2 = { nounwind }
> ```
> and if i drop `[[clang::nounwind]]`, `landingpad` is back.
> Could you please clarify, what do you mean by "help the user" in this case?

The user has said "this function throws exceptions" (`noexcept(false)`) and it's also said "this function never unwinds to its caller" (the attribute) and these statements are in conflict with one another and likely signify user confusion. I would have expected a warning diagnostic here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138958/new/

https://reviews.llvm.org/D138958



More information about the llvm-commits mailing list