[SERVER-31016] return type 'std::__1::cv_status' must match previous return type 'std::__1::cv_status::__lx' when lambda expression has unspecified explicit return type Created: 09/Sep/17  Updated: 30/Oct/23  Resolved: 02/Nov/17

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: 3.4.7
Fix Version/s: 3.4.11

Type: Bug Priority: Minor - P4
Reporter: Ryan Schmidt Assignee: Andrew Morrow (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File lambda-return-type.patch    
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Platforms 2017-11-13
Participants:

 Description   

mongodb 3.4.7 fails to build on OS X 10.8 with the compiler "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)" from Xcode 5.1.1; here is a build log:

https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/35112/steps/install-port/logs/stdio

src/mongo/db/operation_context.cpp:335:13: error: return type 'std::__1::cv_status' must match previous return type 'std::__1::cv_status::__lx' when lambda expression has unspecified explicit return type
            return cv.wait_until(m, deadline.toSystemTimePoint());
            ^
src/mongo/db/operation_context.cpp:340:9: error: return type 'stdx::cv_status' (aka 'std::__1::cv_status') must match previous return type 'std::__1::cv_status::__lx' when lambda expression has unspecified explicit return type
        return cvWaitUntilWithClockSource(clockSource, cv, m, deadline);
        ^
src/mongo/db/operation_context.cpp:366:12: error: no viable conversion from 'const std::__1::cv_status::__lx' to 'StatusWith<stdx::cv_status>'
    return waitStatus;
           ^~~~~~~~~~

The same version builds fine on OS X 10.9 with the compiler "Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)" from Xcode 6.2. Here is that build log:

https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/34415/steps/install-port/logs/stdio

The same version also builds fine on OS X 10.7 with clang 3.9.1 as installed by MacPorts. Here is that build log:

https://build.macports.org/builders/ports-10.7_x86_64_legacy-builder/builds/40825/steps/install-port/logs/stdio

If necessary, we can tell MacPorts to build mongodb with a newer clang on OS X 10.8 as well, but previous versions of mongodb built fine on OS X 10.8 with clang from Xcode so I wanted to let you know in case this is a bug.



 Comments   
Comment by Githook User [ 02/Nov/17 ]

Author:

{'name': 'Andrew Morrow', 'username': 'acmorrow', 'email': 'acm@mongodb.com'}

Message: SERVER-31016 Be more explicit about some lambda return types

Apparently, XCode 5's clang can't see that the two return arms
have the same type. Provide explicit return types to work around.
Branch: v3.4
https://github.com/mongodb/mongo/commit/8c9429d4a94b8c153e057cf18b955a66612f8100

Comment by Ryan Schmidt [ 02/Nov/17 ]

Yes, I'll do that.

Comment by Andrew Morrow (Inactive) [ 02/Nov/17 ]

ryandesign - Sure, I'll apply the patch and run it through our CI system to ensure that it doesn't break anything. I won't really be able to confirm that it still works with XCode 5 easily. I'll ping the ticket once I've committed a fix. After that would you mind confirming for me that it fixes things on your side?

Comment by Ryan Schmidt [ 31/Oct/17 ]

I would prefer not to. Aside from my dislike of git and the inconvenience of creating pull requests, I would prefer not to be listed as the author of changes you wrote and which are in a language I don't understand. I'll attach the patch I used here though if you want to commit it.

Comment by Andrew Morrow (Inactive) [ 31/Oct/17 ]

Awesome. Want to send us a PR?

Comment by Ryan Schmidt [ 31/Oct/17 ]

I think I've understood enough about lambdas now to guess that this is the additional change you're suggesting:

--- src/mongo/db/operation_context_test.cpp.orig        2017-10-18 11:01:51.000000000 -0500
+++ src/mongo/db/operation_context_test.cpp     2017-10-31 16:03:27.000000000 -0500
@@ -231,7 +231,7 @@
                                                                  Date_t maxTime) {
 
         auto barrier = std::make_shared<unittest::Barrier>(2);
-        auto task = stdx::packaged_task<stdx::cv_status()>([=] {
+        auto task = stdx::packaged_task<stdx::cv_status()>([=]() -> stdx::cv_status {
             if (maxTime < Date_t::max()) {
                 txn->setDeadlineByDate(maxTime);
             }

With that additional change, it builds! Thanks!

Comment by Andrew Morrow (Inactive) [ 31/Oct/17 ]

I think the same fix will work there: just give the lambda passed into the packaged_task a trailing return type of stdx::cv_status.

Comment by Ryan Schmidt [ 29/Oct/17 ]

Thanks for your help; sorry I didn't respond sooner. The patch you provided allows compilation to proceed further, but fails later with a similar error:

:info:build src/mongo/db/operation_context_test.cpp:245:17: error: return type 'std::__1::cv_status::__lx' must match previous return type 'stdx::cv_status' (aka 'std::__1::cv_status') when lambda expression has unspecified explicit return type
:info:build                 return stdx::cv_status::no_timeout;
:info:build                 ^

Comment by Andrew Morrow (Inactive) [ 17/Oct/17 ]

Hi ryandesign - I'm closing this ticket because there has been no activity on it for some time. I assume that you have either applied a local patch to address the issue, or that this is no longer a problem for you for other reasons. Please feel free to re-open the ticket or comment on it if there is additional help I can provide.

Comment by Andrew Morrow (Inactive) [ 09/Oct/17 ]

ryandesign - Just circling back to this ticket to see if you were able to verify my proposed fix. If so I would still encourage you to open a PR.

Comment by Andrew Morrow (Inactive) [ 20/Sep/17 ]

ryandesign - Were you able to test out my suggested change? Did it fix the issue for you?

Comment by Andrew Morrow (Inactive) [ 14/Sep/17 ]

Hi ryandesign -

I had something like this in mind:

diff --git a/src/mongo/db/operation_context.cpp b/src/mongo/db/operation_context.cpp
index 8151fe97df..41b54eb661 100644
--- a/src/mongo/db/operation_context.cpp
+++ b/src/mongo/db/operation_context.cpp
@@ -325,7 +325,7 @@ StatusWith<stdx::cv_status> OperationContext::waitForConditionOrInterruptNoAsser
         deadline = std::min(deadline, getDeadline());
     }
 
-    const auto waitStatus = [&] {
+    const auto waitStatus = [&]() -> stdx::cv_status {
         if (Date_t::max() == deadline) {
             cv.wait(m);
             return stdx::cv_status::no_timeout;

Note also that this appears to only affect the v3.4 branch (well, maybe 3.2 as well but I didn't check) - this code has changed in master. So if you validate this fix, please create a GitHub PR against the v3.4 branch, and I can run it through our CI loop and get it merged.

Comment by Ryan Schmidt [ 13/Sep/17 ]

I'd be happy to try out some changes, but I haven't used the C++ features you mentioned so I'm not sure what changes to make. Could you attach possible diffs to this issue for me to try?

Comment by Andrew Morrow (Inactive) [ 13/Sep/17 ]

Hi ryandesign - Thanks for the bug report.

You have identified a weakness in our current CI environment, in that we don't actually build on macOS 10.8 with XCode 5. We set it as the minimum compiler version that we enforce, but I believe we actually do the official 3.4 builds with XCode 7 on a much newer macOS version, so this slipped by us.

Given that, we don't really have a straightforward way to validate a fix for this. However, I think that the answer to this is probably as simple as either giving the lambda a trailing return type of stdx::cv_status, or wrapping the call to cv.wait_until in a stdx::cv_status constructor.

It is interesting to me that the more recent compilers can see that this code is fine, so I suspect that this is really a bug in Xcode 5. Since you are in a position to repro with the configuration that you have, would you mind trying out one of the above suggestions, and, if one of them works, posting a CR? We will be able to get that merged as long as it tests clean in our CI system.

Also, an FYI that MongoDB 3.5 (soon to be 3.6) has bumped the minimum to Xcode 8.

Comment by Ryan Schmidt [ 09/Sep/17 ]

I should be more specific about versions: mongodb 3.2.x built fine on OS X 10.8 with clang from Xcode. mongodb 3.4.0 and later don't.

Generated at Thu Feb 08 04:25:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.