-
Notifications
You must be signed in to change notification settings - Fork 546
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
CXX-2796 Restore external polyfill library and stdlib support #1086
Conversation
…l polyfill libraries
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.
LGTM with minor changes.
src/bsoncxx/include/bsoncxx/v_noabi/bsoncxx/stdx/make_unique.hpp
Outdated
Show resolved
Hide resolved
PR has been updated following merge of #1075. This PR now fully resolves CXX-2796. Latest changes verified by this patch. Notable changes:
Use of mnmlstc/core and Boost equivalents as polyfills is restored to r3.9.0 behavior (sans experimental stdlib, removed by 8e1c47a). For better consistency with other polyfills, the Boost polyfill was updated to conditionally include a
Same as what was done for
In addition to improving the error messages for type trait equality assertions on failure, when testing against stdlib implementations, the equality assertions are relaxed to assert implication instead. This is to account for deviations in stdlib behavior in the negative cases (e.g. https://godbolt.org/z/P5ab6W46W). Instead of
Rather than conditional inclusion of potentially-ambiguous overloads based on polyfill configuration, explicit overloads for all view/value/view_or_value arguments are defined instead to address the potential ambiguity issues.
Some changes were made to reduce inclusion of unrelated symbols in the diff report.
Overlooked that config-time CMake paths must be Windows-based.
The |
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.
LGTM. Nicely done. The test improvements are appreciated.
void init_from_static(bsoncxx::document::view_or_value doc); | ||
|
||
// | ||
// Constructs a new scoped_bson_t from a document view_or_value. |
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.
// Constructs a new scoped_bson_t from a document view_or_value. | |
// Constructs a new scoped_bson_t from a document. |
Another drive-by fix: added missing macro guards for |
I'm not sure what the point of all of my work was if we're just bringing back all the old polyfill support anyway. Why did I do anything at all if it just adds another configuration that we need to test? @kevinAlbs @eramongodb |
@vector-of-bool I expect restoring the polyfills prevents possible source breaking changes. Quoting from a slack conversation with @eramongodb (which I should have included in the ticket):
The removal of the other polyfills (CXX-2797) is marked for the next major release (4.0.0). That said, I think think the bsoncxx polyfills provide value in the 3.x releases. Users on pre C++17 compilers can use the bsoncxx polyfills to avoid using Boost / MNMLSTC. |
@vector-of-bool This PR does not invalidate the work done on bsoncxx polyfill implementations. We do want to exclusively use the bsoncxx implementation for pre-C++17 configurations and drop external polyfill libraries. We just can't do it right now, for the upcoming 3.10 release, because that would violate our commitment to SemVer API versioning by introducing source-breaking changes in a minor version release. Recent interest and efforts to schedule a 4.0 major version release is primarily and directly motivated by our desire to resolve CXX-2797 "Remove MNMLSTC and Boost from CMake scripts and docs". Most of the changes in this PR are expected to be reverted or obsoleted by the 4.0 release as part of CXX-2797. To that end, this PR makes efforts to drive migration by users to using the bsoncxx implementations in the 3.10 release by adding CMake deprecation messages to all external library polyfill configurations, either via
This PR (1) documents external polyfill library configurations as deprecated for the upcoming 3.10 minor version, (2) raises CMake deprecation warnings for such configurations, and (3) provides opt-in configuration settings to address deprecation warnings and upgrade to using the bsoncxx polyfill implementation before the upcoming 4.0 major version release when the breaking change occurs. It is in our best interest to schedule the 4.0 release as soon as able so that we can finally address polyfill library configuration complexity and resolve CXX-2797; this PR ensures we are not violating SemVer API versioning requirements along the way. |
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.
Sorry for the delay, and apologies for the brief existential dread. LGTM, with only a few minor comments/questions.
scoped_bson_t::scoped_bson_t(bsoncxx::document::view_or_value doc) | ||
: _is_initialized{true}, _doc{std::move(doc)} { | ||
doc_to_bson_t(*_doc, &_bson); | ||
} | ||
|
||
void scoped_bson_t::init_from_static(bsoncxx::document::view_or_value doc) { | ||
_is_initialized = true; | ||
_doc = std::move(doc); | ||
doc_to_bson_t(*_doc, &_bson); | ||
} | ||
|
||
scoped_bson_t::scoped_bson_t(bsoncxx::document::view doc) | ||
: scoped_bson_t(bsoncxx::document::view_or_value(doc)) {} | ||
|
||
void scoped_bson_t::init_from_static(bsoncxx::document::view doc) { | ||
this->init_from_static(bsoncxx::document::view_or_value(doc)); | ||
} | ||
|
||
scoped_bson_t::scoped_bson_t(bsoncxx::document::value doc) | ||
: scoped_bson_t(bsoncxx::document::view_or_value(std::move(doc))) {} | ||
|
||
void scoped_bson_t::init_from_static(bsoncxx::document::value doc) { | ||
this->init_from_static(bsoncxx::document::view_or_value(std::move(doc))); | ||
} | ||
|
||
scoped_bson_t::scoped_bson_t(bsoncxx::stdx::optional<bsoncxx::document::view_or_value> doc) { | ||
if (doc) { | ||
_doc = std::move(doc); | ||
doc_to_bson_t(*_doc, &_bson); | ||
this->init_from_static(std::move(*doc)); | ||
} | ||
} |
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.
Is there an explanation on why these constructors needed to be revived? I'm guessing that one or more of the optional impls doesn't "do the right thing"?
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.
Correct. Rather than dealing with inconsistent optional<T>
converting constructor behavior across configurations, settled on making it definitively unambiguous on all implementations for all view/value/view_or_value/optional<view_or_value> arguments expected to be given.
|
||
**DO NOT** change your project's polyfill if you need to create a | ||
stable binary interface. | ||
The mongocxx driver uses C++17 features `std::optional` and `std::string_view`. |
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.
Could this section -- repeated between {linux,macos,windows}.md
-- be refactored into a separate page?
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.
Good idea. Added a new mongocxx-v3/polyfill-selection
page that is linked to from the per-OS installation pages.
@@ -157,6 +155,9 @@ option(BUILD_SHARED_LIBS_WITH_STATIC_MONGOC | |||
OFF | |||
) | |||
|
|||
# Allow the user to opt into using bsoncxx implementations for C++17 polyfills by default. | |||
option(ENABLE_BSONCXX_POLY_USE_IMPLS "Enable using bsoncxx implementations of C++17 polyfills for pre-C++17 configurations by default" OFF) |
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'm iffy on this CMake setting name. It is unclear what it means compared to USE_BOOST
, USE_STD
, USE_MNMLSTC
etc. I'm unfortunately not sure on what a better name might be.
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 went back and forth several times on what to name this configuration and settled on "bsoncxx implementations" -> "IMPLS" due to the ABI tag parameter b
already being used for Boost. This way i
can be used for "(bsoncxx) implementations". The hope is that descriptions and documentation will be enough to make its purpose/meaning clear.
+++ | ||
date = "2024-02-20T00:00:00-00:00" | ||
title = "Choosing a C++17 Polyfill" | ||
[menu.main] | ||
identifier = "mongocxx3-polyfill-selection" | ||
parent = "mongocxx3" | ||
weight = 8 | ||
+++ |
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 must admit I do not understand how the value of some of these fields are supposed to be set (date and weight in particular), so simply copied the template from similar files.
Description
This PR
partiallyresolves CXX-2796.Full resolution pending #1075.(Merged.) Verified by this patch.This PR restores polyfill library (pre-C++17) and stdlib (post-C++17) support, including the explicit setting of a
BSONCXX_POLY_USE_*
option regardless of the selected C++ standard. This avoids the pending r3.10.0 release from potentially causing source-breaking changes in downstream code that depends on expectations of the underlying type forbsoncxx::stdx::string_view
orbsoncxx::stdx::optional<T>
being consistent with a selected polyfill library.BSONCXX_USE_POLY_IMPLS
This PR adds a new CMake option
BSONCXX_POLY_USE_IMPLS
to opt-into using bsoncxx implementations for polyfills. This configuration is denoted asi
in the ABI tag. TheENABLE_BSONCXX_POLY_USE_IMPLS
option controls whether bsoncxx implementations are considered by default polyfill library selection (when no polyfill library is explicitly selected by the user).ENABLE_BSONCXX_POLY_USE_IMPLS
is currentlyOFF
by default to avoid source-breaking changes in user code that depends on current default polyfill library selection behavior for pre-C++17 configurations. This option is expected to be set toON
by default in an upcoming major release as part of CXX-2797. Installation documentation is updated to recommend users setBSONCXX_POLY_USE_IMPLS=ON
to avoid external library dependencies. The external polyfill library options are now deprecated in favor of bsoncxx implementations per CXX-2797. CMake deprecation warning messages are also added accordingly.Note,
BSONCXX_POLY_USE_IMPLS=ON
is currently broken due to #1075 not yet being merged (there is no bsoncxx implementation ofstd::optional
).Restoring Polyfill Support
This PR restores polyfill selection behavior and support to be consistent with the r3.9.0 release.
This was fairly straightforward for
string_view.hpp
, which, relative to r3.9.0 (sans using-decl refactor changes), simply appends theBSONCXX_POLY_USE_IMPLS
case to the list of alternatives before the#error
case:This pattern is expected to be applied similarly to the
optional.hpp
header after #1075 is merged in a followup PR.The
make_unique.hpp
header is different. Because it only provides non-exported function templates, its impact on source-compatibility is minimal (situations where our changes can break source would be considered abnormal usage of these interfaces). Furthermore, r3.9.0 introduced a C++20 polyfill formake_unique_for_overwrite<T>()
which is not covered by the usual C++17 external polyfill libraries. Because neither of these features are related to C++17-compatibility, this PR proposes using feature test macros for bothmake_unique<T>()
(C++14) andmake_unique_for_overwrite<T>()
(C++20) to select bsoncxx vs. stdlib implementations, independent of the C++17 polyfill library configuration.Restoration of r3.9.0 behavior can be verified by the ABI stability reports for both polyfill and stdlib configurations (compared to those in the latest commit for polyfill and stdlib).
Miscellaneous
string_view
tests for non-bsoncxx polyfills due to compatibility and conformance issues. We only need the tests to test our implementations anyways (+ stdlib to verify test consistency).--non-reachable-types
flag due to producing undesirable errors beyond what we want to test.