Skip to content

Conversation

@malavikasamak
Copy link
Contributor

Unsafe operation in methods that are already annotated with clang::unsafe_buffer_usage attribute, should not trigger a warning. This is because, the developer has already identified the method as unsafe and warning at every unsafe operation is redundant.

rdar://138644831

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Feb 4, 2025
@llvmbot
Copy link
Member

llvmbot commented Feb 4, 2025

@llvm/pr-subscribers-clang

Author: Malavika Samak (malavikasamak)

Changes

Unsafe operation in methods that are already annotated with clang::unsafe_buffer_usage attribute, should not trigger a warning. This is because, the developer has already identified the method as unsafe and warning at every unsafe operation is redundant.

rdar://138644831


Full diff: https://github.com/llvm/llvm-project/pull/125671.diff

2 Files Affected:

  • (modified) clang/lib/Sema/AnalysisBasedWarnings.cpp (+3)
  • (modified) clang/test/SemaCXX/warn-unsafe-buffer-usage-function-attr.cpp (+41-6)
diff --git a/clang/lib/Sema/AnalysisBasedWarnings.cpp b/clang/lib/Sema/AnalysisBasedWarnings.cpp
index 589869d0186575..7111dfd523a101 100644
--- a/clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ b/clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -2610,6 +2610,9 @@ void clang::sema::AnalysisBasedWarnings::IssueWarnings(
 
   // The Callback function that performs analyses:
   auto CallAnalyzers = [&](const Decl *Node) -> void {
+    if (isa<FunctionDecl>(Node) && Node->hasAttr<UnsafeBufferUsageAttr>())
+        return;
+
     // Perform unsafe buffer usage analysis:
     if (!Diags.isIgnored(diag::warn_unsafe_buffer_operation,
                          Node->getBeginLoc()) ||
diff --git a/clang/test/SemaCXX/warn-unsafe-buffer-usage-function-attr.cpp b/clang/test/SemaCXX/warn-unsafe-buffer-usage-function-attr.cpp
index 724d444638b57e..ef724acc761dbd 100644
--- a/clang/test/SemaCXX/warn-unsafe-buffer-usage-function-attr.cpp
+++ b/clang/test/SemaCXX/warn-unsafe-buffer-usage-function-attr.cpp
@@ -119,16 +119,15 @@ struct HoldsUnsafeMembers {
 
     [[clang::unsafe_buffer_usage]]
     HoldsUnsafeMembers(int i)
-        : FromCtor(i),  // expected-warning{{function introduces unsafe buffer manipulation}}
-          FromCtor2{i}  // expected-warning{{function introduces unsafe buffer manipulation}}
-    {}
+        : FromCtor(i),
+          FromCtor2{i} {}
 
     HoldsUnsafeMembers(float f)
         : HoldsUnsafeMembers(0) {}  // expected-warning{{function introduces unsafe buffer manipulation}}
 
     UnsafeMembers FromCtor;
     UnsafeMembers FromCtor2;
-    UnsafeMembers FromField{3};  // expected-warning 2{{function introduces unsafe buffer manipulation}}
+    UnsafeMembers FromField{3};  // expected-warning {{function introduces unsafe buffer manipulation}}
 };
 
 struct SubclassUnsafeMembers : public UnsafeMembers {
@@ -138,8 +137,7 @@ struct SubclassUnsafeMembers : public UnsafeMembers {
 
     [[clang::unsafe_buffer_usage]]
     SubclassUnsafeMembers(int i)
-        : UnsafeMembers(i)  // expected-warning{{function introduces unsafe buffer manipulation}}
-    {}
+        : UnsafeMembers(i){}
 };
 
 // https://github.com/llvm/llvm-project/issues/80482
@@ -245,3 +243,40 @@ struct AggregateViaDefaultInit {
 void testAggregateViaDefaultInit() {
     AggregateViaDefaultInit A;
 };
+
+struct A {
+  int arr[2];
+
+  [[clang::unsafe_buffer_usage]]
+  int *ptr;
+};
+
+namespace std{
+  template <typename T> class span {
+
+   T *elements;
+
+   public:
+
+   constexpr span(T *, unsigned){}
+
+   template<class Begin, class End>
+   constexpr span(Begin first, End last){}
+
+   constexpr T* data() const noexcept {
+     return elements;
+   }
+ };
+}
+
+[[clang::unsafe_buffer_usage]]
+void check_no_warnings(unsigned idx) {
+  int *arr = new int[20];
+
+  int k = arr[idx]; // no-warning
+
+  std::span<int> sp = {arr, 20}; // no-warning
+  A *ptr = reinterpret_cast<A*> (sp.data()); // no-warning
+  A a;
+  a.ptr = arr; // no-warning
+}

@github-actions
Copy link

github-actions bot commented Feb 4, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

@malavikasamak malavikasamak force-pushed the msamak-138644831-sprss-warn-func-attr branch from 63fccde to b511871 Compare February 4, 2025 17:34
Copy link
Collaborator

@shafik shafik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this have a release note?

Copy link
Collaborator

@erichkeane erichkeane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rdar://138644831
DO we have to!?!

I don't object to the commit itself once @Fznamznon and @shafik are happy.

@malavikasamak
Copy link
Contributor Author

Should this have a release note?
That seems like a good idea, since this is changing the expected behavior of the warning. Will add it in the next verion.

Copy link
Contributor

@ziqingluo-90 ziqingluo-90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!
I agree with @Fznamznon 's comment. Please consider addressing it.

@malavikasamak
Copy link
Contributor Author

@dtarditi FYI.

…otated with clang::unsafe_buffer_usage attribute

Unsafe operation in methods that are already annotated with clang::unsafe_buffer_usage attribute,
should not trigger a warning. This is because, the developer has already identified
the method as unsafe and warning at every unsafe operation is redundant.

(rdar://138644831)
@malavikasamak malavikasamak force-pushed the msamak-138644831-sprss-warn-func-attr branch from b511871 to 821a4b4 Compare February 19, 2025 00:36
@malavikasamak
Copy link
Contributor Author

@Fznamznon and @shafik: Thanks for the review. I have addressed your comments. Please take a look.

Copy link
Contributor

@dtarditi dtarditi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a suggestion for some additional test cases.

@dtarditi
Copy link
Contributor

Also, please avoid force pushes if you can. It confuses the PR history.

Copy link
Contributor

@dtarditi dtarditi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good - thank you for adding the tests.

@malavikasamak malavikasamak merged commit 041b7f5 into llvm:main Feb 25, 2025
12 checks passed
malavikasamak added a commit to swiftlang/llvm-project that referenced this pull request Feb 26, 2025
…otated with clang::unsafe_buffer_usage attribute (llvm#125671)

Unsafe operation in methods that are already annotated with
clang::unsafe_buffer_usage attribute, should not trigger a warning. This
is because, the developer has already identified the method as unsafe
and warning at every unsafe operation is redundant.

rdar://138644831

---------

Co-authored-by: MalavikaSamak <[email protected]>
(cherry picked from commit 041b7f5)
malavikasamak added a commit to swiftlang/llvm-project that referenced this pull request Feb 27, 2025
…r methods annotated with clang::unsafe_buffer_usage attribute (llvm#125671)

[Cherry-pick][Wunsafe-buffer-usage] Turn off unsafe-buffer warning for methods annotated with clang::unsafe_buffer_usage attribute (llvm#125671)
malavikasamak added a commit that referenced this pull request Apr 10, 2025
…tribute (#135087)

Update the documentation for the unsafe_buffer_usage attribute to
capture the new behavior introduced by
#125671

Co-authored-by: MalavikaSamak <[email protected]>
llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request Apr 10, 2025
…er_usage attribute (#135087)

Update the documentation for the unsafe_buffer_usage attribute to
capture the new behavior introduced by
llvm/llvm-project#125671

Co-authored-by: MalavikaSamak <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants