-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[Clang] Implement CWG2813: Class member access with prvalues #120223
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
[Clang] Implement CWG2813: Class member access with prvalues #120223
Conversation
Create Sema::DiagnoseDiscardedNodiscard Remove warn_discarded_class_member_access and call Sema::DiagnoseDiscardedNodiscard instead Remove MakeGLValue from the MSPropertyRefExpr path Fix [[nodiscard]] test in test/CXX Add test for [[nodiscard]] and explicit object member functions in test/SemaCXX
…-explicit-object-member-function-call
✅ With the latest revision this PR passed the C/C++ code formatter. |
clang/lib/Sema/SemaStmt.cpp
Outdated
// Don't diagnose discarded left of dot in static class member access | ||
// because its type is "used" to determine the class to access | ||
//if (DiagID == diag::warn_discarded_class_member_access) | ||
// return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be deleted at this point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few nits, else LGTM.
clang/include/clang/Sema/Sema.h
Outdated
@@ -10659,6 +10659,11 @@ class Sema final : public SemaBase { | |||
SourceLocation EndLoc); | |||
void ActOnForEachDeclStmt(DeclGroupPtrTy Decl); | |||
|
|||
/// DiagnoseDiscardedExprMarkedNodiscard - Given an expression that is | |||
/// semantically a discarded-value expression, diagnose if any [[nodiscard]] | |||
/// value has been discarded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// value has been discarded | |
/// value has been discarded. |
clang/lib/Sema/SemaExprMember.cpp
Outdated
// an enumerator, the first expression is a discarded-value expression; if | ||
// the id-expression names a non-static data member, the first expression | ||
// shall be a glvalue. | ||
auto MakeDiscardedValue = [&] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer some more descriptive names here? Perhaps ConvertBaseExprToDiscardedValue
and ConvertBaseExprToGLValue
?
…0223) This is a rebase of llvm#95112 with my own feedback apply as @MitalAshok has been inactive for a while. It's fairly important this makes clang 20 as it is a blocker for llvm#107451 Change-Id: I2261810f7c8d7dd8b3e3412c0814a528d7c7b91c --- [CWG2813](https://cplusplus.github.io/CWG/issues/2813.html) prvalue.member_fn(expression-list) now will not materialize a temporary for prvalue if member_fn is an explicit object member function, and prvalue will bind directly to the object parameter. The E1 in E1.static_member is now a discarded-value expression, so if E1 was a call to a [[nodiscard]] function, there will now be a warning. This also affects C++98 with [[gnu::warn_unused_result]] functions. This should not affect C where TemporaryMaterializationConversion is a no-op. Closes llvm#100314 Fixes llvm#100341 --------- Co-authored-by: Mital Ashok <[email protected]> (cherry picked from commit db93ef1) Change-Id: Ic277d16bc8611b9d383cb890da3eda0ef1646555
llvm/llvm-project#120223 became more strict about discarded value expressions. The current std::forward expressions triggered a no-discard warning/error. It seems like we can remove the `std::forward` on the lvalue reference in these visitor functions anyway to resolve this error. Fixed: 385748190 Change-Id: Iaf51848f82f0979f72a26736d33b50ad60738de4 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1179435 Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: Caslyn Tonelli <[email protected]> Reviewed-by: Casey Dahlin <[email protected]>
llvm/llvm-project#120223 became more strict about discarded value expressions. This CL moves the array reference into a local variable to operate on. Bug: 385748190 Change-Id: Iafe9ff737500c7bab8f55d3e216c5606048ab4c2 Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1179388 Reviewed-by: Justin Mattson <[email protected]> Fuchsia-Auto-Submit: Caslyn Tonelli <[email protected]> Commit-Queue: Auto-Submit <[email protected]>
llvm/llvm-project#120223 became more strict about discarded value expressions. This CL moves the array reference into a local variable to operate on. Bug: 385748190 Change-Id: I468bc0e122778a867ea452535be5d4562802264e Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1179632 Reviewed-by: Karl Ward <[email protected]> Commit-Queue: Auto-Submit <[email protected]> Fuchsia-Auto-Submit: Caslyn Tonelli <[email protected]>
llvm/llvm-project#120223 became more strict about discarded value expressions. The current std::forward expressions triggered a no-discard warning/error. It seems like we can remove the `std::forward` on the lvalue reference in these visitor functions anyway to resolve this error. Original-Fixed: 385748190 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1179435 Original-Revision: f5151dcdb438a72b806da2dd8efdf1dcefe45583 GitOrigin-RevId: 1da2bddea99f38cf500975599e0a17cf1e649236 Change-Id: I053bca01ca47a110a9e3ccd29d3c8ce19f7588ef
llvm/llvm-project#120223 became more strict about discarded value expressions. This CL moves the array reference into a local variable to operate on. Original-Bug: 385748190 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1179388 Original-Revision: 24958deb6cd71533593a4be6cb4b339b0f69be63 GitOrigin-RevId: a1e1527c35b8fc8e4368ff974ea5ac3f3108fc80 Change-Id: I84e72196e08e5372cda062963625d51d5b67e629
llvm/llvm-project#120223 became more strict about discarded value expressions. This CL moves the array reference into a local variable to operate on. Original-Bug: 385748190 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1179632 Original-Revision: bac0bfd54ea3efbc387ccf36a5a8e2e99debce0c GitOrigin-RevId: d4eb0af1986902cf6b06628fb3f5965e68d9b45b Change-Id: I97d076d5263521cf69e59f9e8a479dbeba2fa148
It looks like this is linked to: #131410 and it is not clear to me the diagnostic in these cases makes a lot of sense or at least the motivation does not feel strong to me. This new approach feels evolutionary to me and if this was the intent then I am not sure we should implement it. |
…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
…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)
…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)
This is a rebase of #95112 with my own feedback apply as @MitalAshok has been inactive for a while.
It's fairly important this makes clang 20 as it is a blocker for #107451
CWG2813
prvalue.member_fn(expression-list) now will not materialize a temporary for prvalue if member_fn is an explicit object member function, and prvalue will bind directly to the object parameter.
The E1 in E1.static_member is now a discarded-value expression, so if E1 was a call to a [[nodiscard]] function, there will now be a warning. This also affects C++98 with [[gnu::warn_unused_result]] functions.
This should not affect C where TemporaryMaterializationConversion is a no-op.
Closes #100314
Fixes #100341