Fix Arthur's nits.
I see. I can change this patch so it just implicitly deletes the operator in case we decide to pick function pointers, without the hard error introduced by the previous patch.
And if the comitee decides to stop providing relational operators for function pointers, we can revisit this.
@rjmccall Added some tests covering these semantics: clang/test/SemaObjCXX/block-capture.mm and also some extra documentation to checkEscapingByref. Not sure if I got the terminology right here..
@Quuxplusone any other interesting corner cases for these new tests?
(In a build prior to https://reviews.llvm.org/rGc60dd3b2626a4d9eefd9f82f9a406b0d28d3fd72 "Revert '[clang] NRVO: Improvements and handling of more cases.'") I see the following (reduced from https://git.libreoffice.org/core/+/649313625b94e6b879848fc19b607b74375100bf/o3tl/qa/compile-temporary.cxx) started to fail under -std=c++2b with this change (and continues to compile fine with -std=c++20):
It is not clear to me whether that is an intended change in behavior according to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html "Simpler implicit move", or whether it is a bug in this implementation.
Mon, Jun 14
When __block variables get moved to the heap, they're supposed to be moved if possible, not copied. It looks like PerformMoveOrCopyInitialization requires NRVO info to be passed in to ever do a move. Maybe it's being passed in wrong when building __block copy expressions in some situation.
Found the culprit, that functionality was implemented in checkEscapingByref, and it was a bit of a shocker that such a thing was just hiding in a function with such an unassuming name :)
Also surprising to find here another user of the two-step overload resolution, that also escaped our radar.
There is a C++ proposal (P2266) to replace that mechanism with something much simpler.
Sun, Jun 13
Sat, Jun 12
Fri, Jun 11
Look through AttributedType when obtaining FunctionDecl return type.
Thu, Jun 10
Actually we can land it now. @rsmith gave me the go ahead in private. The windows pipeline passes. The latest debian build failure is some random fortran thing, so we are good.
Also by the way D100713 is not really a dependency here, this DR can land on it's own if that is not clear.
Now that we have isPRValue, this is hopefully less controversial now :)
Wed, Jun 9
Tue, Jun 8
Implement rsmith's suggestions.
(esp if someone in the future wants to add Expr::isRValue() with the C++ meaning of prvalue || xvalue).
Mon, Jun 7
@rsmith what do you think of the following strategy as a follow up to this patch:
Sat, Jun 5
Since we can still crash with user defined conversion operators for any builtin types not supported by getComparisonCategoryForBuiltinCmp (many others), I will make a follow up patch to just replace that assert with a deleted result.
I created a DR which proposes the renaming as rsmith suggested: https://reviews.llvm.org/D103720
Fri, Jun 4
some small comment changes
apply format patch to tests
May 14 2021
What do we think about renaming isRValue() to isPRValue() and renaming VK_RValue to VK_PRValue, adding a "real" isRValue(), and then performing this cleanup? I think the current state of treating "rvalue" as sometimes meaning rvalue and sometimes meaning "prvalue" is unhelpful and confusing, and this change makes it worse because isRValue *could* be checking for an rvalue whereas a comparison against VK_RValue more clearly is only looking for one specific value category rather than two.
Not sure how to feel about this, the value categories are already hard to grasp for most C++ programmers. To solve the implicit move concerns with a new value category seems like cracking a nut with a sledgehammer. But that's not directly related to this change, we can discuss this when the change is there.
Again, I'm not sure if it helps to use getDecltypeForParenthesizedExpr where we don't actually have the decltype of a parenthesized expression.
It's probably not entirely coincidental, but things aren't defined this way.
Apr 21 2021
Apr 20 2021
Initial implementation, still WIP.
Apr 18 2021
The change seems to be correct, but I'm wondering if x.getValueKind() == VK_*Value doesn't have one advantage over x.is*Value(): it's obvious that this is exclusive with the other values. Especially with isRValue() it might not be so obvious, because Clang doesn't follow the C++11 terminology with this.
But it's admittedly shorter, so I'd be willing to approve this.
Split 'getValueKind' cleanup into a separate patch.
Apr 17 2021
Apr 16 2021
Apr 15 2021
- Added doc to disallowNRVO
- Also detect implicit return type for blocks.
Apr 13 2021
- Changed the downgrade* function name to disallowNRVO, given second thought, I think it's appropriate name.
- Change to one variable declaration per statement as per Arthur's review.
Actually, there is still something not quite right with this patch that I have to finish investigating.
- Address rsmith review comments.
Apr 12 2021
Apr 11 2021
- Removes code that tried to allow copy elision for functions with dependent 'auto' return types. The reason is explained in new comments. Will try to address these in future work.
- Addresses aaronpuchert's review points.
Apr 10 2021
- Addresses aaronpuchert's review points.
Apr 9 2021
Apr 6 2021