Skip to content

Clang 20 warns on nodiscard-call.static_member_function() #131410

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
timsong-cpp opened this issue Mar 15, 2025 · 1 comment · Fixed by #131450
Closed

Clang 20 warns on nodiscard-call.static_member_function() #131410

timsong-cpp opened this issue Mar 15, 2025 · 1 comment · Fixed by #131450
Labels
clang:diagnostics New/improved warning or error message in Clang, but not in clang-tidy or static analyzer confirmed Verified by a second party

Comments

@timsong-cpp
Copy link

Clang 20 started issuing warnings on code like

struct mapping {
    static bool is_exhaustive();
};
template<class M>
struct mdspan {
    [[nodiscard]] M const& mapping() const;
};

void f() {
    mdspan<mapping> s;
    s.mapping().is_exhaustive();  // warning: ignoring return value of function declared with 'nodiscard' attribute [-Wunused-result]
}

Whatever the standard says about discarded-value expressions, warning on this code - basically a simplified std::mdspan - is undesirable. The actual mapping() member is marked nodiscard in at least one standard library implementation.

Not only is there nothing particularly wrong about calling a static member function like this, but here is_exhaustive() is a static member only as an implementation detail of the specific mapping class (in a different class, the result can depend on the state of *this and hence it needs to be non-static), so that it would be wrong for the user to call it statically in generic code. There's also no easy way to suppress the warning.

So the only way for the author of a template like this is to not mark mapping() as [[nodiscard]]. Which, it should go without saying, is rather unfortunate. s.mapping(); should trigger a warning because the user probably meant something else.

This is presumably introduced by db93ef1. I'm surprised that the release notes change did not even mention the impact on warnings.

@llvmbot llvmbot added the clang Clang issues not falling into any other category label Mar 15, 2025
@EugeneZelenko EugeneZelenko added clang:diagnostics New/improved warning or error message in Clang, but not in clang-tidy or static analyzer and removed clang Clang issues not falling into any other category labels Mar 15, 2025
@shafik
Copy link
Collaborator

shafik commented Mar 15, 2025

I left a comment on the PR, it is not clear to me how it was intended for folks to deal with cases like this, at least not based on reading the PR.

@cor3ntin cor3ntin added the confirmed Verified by a second party label Mar 15, 2025
cor3ntin added a commit to cor3ntin/llvm-project that referenced this issue Mar 15, 2025
…mber access

For an expression `nodiscard_function().static_member(),
the nodiscard warnings added by llvm#120223, are not useful or actionable,
and are disruptive to some library implementations; we just remove them.

Fixes llvm#131410
@cor3ntin cor3ntin marked this as a duplicate of #131458 Mar 15, 2025
cor3ntin added a commit to cor3ntin/llvm-project that referenced this issue Mar 18, 2025
…mber access (llvm#131450)

For an expression `nodiscard_function().static_member(), the nodiscard
warnings added by llvm#120223, are not useful or actionable, and are
disruptive to some library implementations; we just remove them.

Fixes llvm#131410

(cherry picked from commit 9a1e390)
swift-ci pushed a commit to swiftlang/llvm-project that referenced this issue Mar 18, 2025
…mber access (llvm#131450)

For an expression `nodiscard_function().static_member(), the nodiscard
warnings added by llvm#120223, are not useful or actionable, and are
disruptive to some library implementations; we just remove them.

Fixes llvm#131410

(cherry picked from commit 9a1e390)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:diagnostics New/improved warning or error message in Clang, but not in clang-tidy or static analyzer confirmed Verified by a second party
Projects
None yet
5 participants