[mlir] Silence -Wdangling-assignment-gsl in OperationSupport.h #126140

smeenai · 2025-02-06T22:10:51Z

This warning is causing lots of build spam when I use a recent Clang as
my host compiler. It's a potential false positive, so silence it until
#126600 is resolved.
Fix variable casing while I'm here.

llvmbot · 2025-02-06T22:11:23Z

@llvm/pr-subscribers-mlir

@llvm/pr-subscribers-mlir-core

Author: Shoaib Meenai (smeenai)

Changes

This warning is causing lots of build spam when I use a recent Clang as
my host compiler. a3b4d91 fixes the
same issue in clangd; apply that fix here too. I also think this is a
potential false positive though. Fix variable casing while I'm here.

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

1 Files Affected:

(modified) mlir/include/mlir/IR/OperationSupport.h (+6-4)

diff --git a/mlir/include/mlir/IR/OperationSupport.h b/mlir/include/mlir/IR/OperationSupport.h
index d4035d14ab74650..bcbf9458ff96e7f 100644
--- a/mlir/include/mlir/IR/OperationSupport.h
+++ b/mlir/include/mlir/IR/OperationSupport.h
@@ -997,13 +997,15 @@ struct OperationState {
     if (!properties) {
       T *p = new T{};
       properties = p;
-      propertiesDeleter = [](OpaqueProperties prop) {
+      constexpr auto deleter = [](OpaqueProperties prop) {
         delete prop.as<const T *>();
       };
-      propertiesSetter = [](OpaqueProperties new_prop,
-                            const OpaqueProperties prop) {
-        *new_prop.as<T *>() = *prop.as<const T *>();
+      propertiesDeleter = deleter;
+      constexpr auto setter = [](OpaqueProperties newProp,
+                                 const OpaqueProperties prop) {
+        *newProp.as<T *>() = *prop.as<const T *>();
       };
+      propertiesSetter = setter;
       propertiesId = TypeID::get<T>();
     }
     assert(propertiesId == TypeID::get<T>() && "Inconsistent properties");

River707 · 2025-02-06T22:24:05Z

This feels like a false positive, but does the error persist if you add a + before the lambda to force conversion to a function pointer?

smeenai · 2025-02-06T22:31:35Z

This feels like a false positive, but does the error persist if you add a + before the lambda to force conversion to a function pointer?

That was the first thing I tried. The warning was still there, and I actually got ASAN failures after making that change, which I wasn't expecting at all.

joker-eph · 2025-02-06T23:34:23Z

If this is a false positive: isn't this a bug to report to clang instead of working around it like this?

smeenai · 2025-02-06T23:50:40Z

Per a3b4d91:

I think this is a false positive for a non-capturing lambda, but I can't
find anything in the standard that guarantees that these have eternal
lifetime.

I'll post a Clang issue to clarify, but this generates a huge amount of build spam, so I think it's worth addressing that even if it's not the ultimate fix.

joker-eph · 2025-02-06T23:52:19Z

Can we disable the warning for this build target instead? With a comment and a link to the clang issue for reeenabling when fixed? That's less intrusive that code changes that we won't track and revert.

smeenai · 2025-02-10T21:31:16Z

I posted #126600 to ask about the warning. I'll try silencing the warning instead here.

This warning is causing lots of build spam when I use a recent Clang as my host compiler. It's a potential false positive, so silence it until llvm#126600 is resolved.

smeenai · 2025-02-10T22:04:27Z

@joker-eph I'm silencing the warning instead now, does it look okay to you?

joker-eph

Thanks!

llvm-ci · 2025-02-11T22:07:59Z

LLVM Buildbot has detected a new failure on builder openmp-offload-sles-build-only running on rocm-worker-hw-04-sles while building mlir at step 5 "compile-openmp".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/140/builds/16752