[SERVER-40147] Upgrade src/third_party/variant-1.3.0 Created: 14/Mar/19 Updated: 29/Oct/23 Resolved: 26/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Jackson | Assignee: | Ryan Egesdahl (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Backport Requested: |
v4.4, v4.2, v4.0, v3.6
|
||||
| Sprint: | Dev Platform 2020-06-01, Dev Platform 2020-06-15, Dev Platform 2020-06-29 | ||||
| Participants: | |||||
| Description |
|
stdx::variant is currently provided by the standard library if std::variant is available. We should either remove the polyfill library, or upgrade it to 1.4.0 and enable it unconditionally. Service Architecture believes that the variant polyfill may be of higher quality than that available with compilers. |
| Comments |
| Comment by Githook User [ 26/Jun/20 ] |
|
Author: {'name': 'Ryan Egesdahl', 'email': 'ryan.egesdahl@mongodb.com', 'username': 'deriamis'}Message: We use a third-party implementation of std::variant on platforms that do |
| Comment by Ryan Egesdahl (Inactive) [ 18/Jun/20 ] |
|
Scratch what I said earlier. It was already being included unconditionally. We were just doing it directly in the source with a full-path #include directive rather than using the build system to inject an include path. I think doing the upgrade and wiring it into the build system properly will address all of the requirements stated here. |
| Comment by Ryan Egesdahl (Inactive) [ 18/Jun/20 ] |
|
I'm going to upgrade the third-party source, but I think enabling it unconditionally needs to be a separate change. Tying the two actions together can complicate things, especially if the second part doesn't go well for some reason. |