• Use __to_underlying
• Don't depend on the exact value of the mask
• Use bitwise NOT according to the definition in the standard

LGTM, but it still needs approval of one of the maintainers.

In D97365#2589584, @curdeius wrote:

• Expose __to_underlying in C++11 onwards.

One small request otherwise LGTM.

Some small issues, but like to see the build pass before approving.

I had a quick look, I'll have a closer look later.

In D97283#2582244, @tmatheson wrote:

In D97283#2582217, @Mordante wrote:

Why doesn't is_signed be updated in the same way? I see the builds on buildkite passing, but the difference between is_unsigned and is_signed look very odd to me.

is_signed is based on the __is_signed builtin, which unlike __is_unsigned is not broken for enums since clang 9 (according to the comment on the is_signed implementation).

Why doesn't is_signed be updated in the same way? I see the builds on buildkite passing, but the difference between is_unsigned and is_signed look very odd to me.

I like the extensive set of tests you added! I'd like to see the build pass before accepting.

@ldionne should we enabling floating point support by a CMake configuration option which is ON by default. The tables aren't small and it could add bloat for embedded devices.

_LIBCPP_NODISCARD_AFTER_CXX17 -> [[nodiscard]] compilers should support it by now, also the AFTER_CXX17 version seems not to be required
Add _LIBCPP_INLINE_VISIBILITY to the functions

• Added a warning as proposed by @tschuett
• Use more concepts as suggested by @miscco
• Rebased on main

In D93593#2577296, @miscco wrote:

Thanks for working on this. It is a considerable library

I am really concerned about doing a "quick" implementation and then being locked in due to ABI issues.

I believe we should spend the time up front to get a clean efficient implementation

Mark the functions not available on older Mac versions. This should fix
Apple back-deployment macosx10.9, the last build failing to pass.

Thanks for your feedback! I'll wait for @ldionne's view on to_underlying before addressing the comments.

• Re-add an colon after UNSUPPORTED, seems I fat fingered the delete after testing, properly disables the nodes prior to C++17.
• Disable for the following builds:
  • Single-treaded
  • No random device
  • No locale This should be looked at later, but for now just want to get all builds in the green.

Rebased on main to merge the already committed part.
@ldionne can you have a look at this patch it should be ready.

1a5c92f68021 should fix this patch. Can you rebase on main to see whether the CI passes for this patch?

• add guards for C++17. This fixes several failing unit tests.
• Removed _Charconv_digits[] from C++03.

• Update the header tests.
• Apply Microsoft's changes of e4bc00e70cbb539f90b803a64a31f0259e21f28
• Include the unit test with a hack, just to avoid code changes.
• Add several TODO's for thing that need to be fixed before the final approval.
• Disable and modify some code.
  • Parts of these changes would nice to be upstreamed. I'll create a PR for MSFT's STL
  • Parts are work-around for unimplemented features in libc++.

It seems this fails to build on Apple due to an issue in _LIBCPP_HAS_NO_CONCEPTS. I'll fix that in main this weekend.

In D96657#2562656, @cjdb wrote:

I'm not sure why Mac OS is failing (and I don't have a Mac to test on at home). It looks like C++20 mode isn't being enabled despite -std=c++2a being in the build config?

Can you use arc to upload the next diff. This will trigger our CI and we can see whether your patch passes all build nodes.

In D94511#2562349, @kamleshbhalui wrote:

I think _LIBCPP_NO_HAS_CHAR8_T should be _LIBCPP_HAS_NO_CHAR8_T since _LIBCPP_NO_HAS_CHAR8_T is used at several places I used it here as well, I can clean it up in
different patch if everyone agrees.

Thanks! Provided it passes CI, LGTM.

Fixes a minor formatting error.
2 unit test with a last minute cleanup breakage
a unit test requiring clang-12 due since it requires e97e9851b227e
properly silence warnings about unused parameter pack arguments

In D96577#2562047, @cjdb wrote:

Yes there seems to be a bug in that code. I've put it in a block for GCC specific code. (This is not obvious due to the lack of indention of the section.)

Oh, it might be because Clang's concepts are incomplete and so the feature-test macro's value is too high for us? Anyway, if you update everything in one fell swoop, I think that'd be best :-)

Add the new headers to CMake and the module map.

Rebase against main.

The concept fix for Apple seems to be working, but needs to be enabled for some existing tests.

@ldionne Friendly ping.

In D96577#2561522, @cjdb wrote:

undoes !_LIBCPP_HAS_NO_CONCEPTS change in an attempt to get the Mac OS build working

Let all unit test require concepts. Test whether that fixes the Apple build issues.

Make _LIBCPP_HAS_NO_CONCEPTS not GCC specific. (The lack of indention made it hard to detect it was a GCC specific section.)

Removed so obsolete comment.
Use the arithmetic concepts directly since they've landed in main.

The MLIR build is now green :-)

It seems modifying the header and building libc++ doesn't rebuild the library. So it seemed to work for me. After I touched format.cpp I could reproduce the issue. Pushed another fix that works for me locally, but I'll keep an eye on the MLIR build server.

Rebased to trigger CI.

Use concept support to disable <format> on older compilers. Note this is intended to be a temporary solution until libc++ requires a modern compiler.
Rebased.

The sanitizer-ppc64be-linux build node uses gcc 7.3.1 and fails http://lab.llvm.org:8011/#/builders/18/builds/749

In D70631#2550277, @STL_MSFT wrote:

Are you fine by me commandeering this patch?

Please go ahead!

For now I'll postpone this patch, if other solutions work I'll abandon this patch. Else I'll have more concrete details why I want to use this solution.

LGTM!

Except for the build issue, LGTM!

In D96230#2550352, @cjdb wrote:

In D96230#2548903, @Mordante wrote:

Do we need to do some tests on
[concept.moveconstructible]/1 http://eel.is/c++draft/concepts#concept.moveconstructible-1 ? Or does constructible_­from and convertible_­to guarantee these conditions hold?

The compiler doesn't check the semantic requirements (right now), so there's nothing to test. If we decide to promote violating the semantic requirements from IFNDR to ill-formed, that's when adding the tests will be helpful (right now they'd likely get in the way).

In D96057#2551513, @ldionne wrote:

This LGTM, let's see if other build bots not covered by our CI complain.

If they do, then we need to migrate them to our CI :-).

Also look at the remarks in D96230 that are applicable here.

Do we need to do some tests on
[concept.moveconstructible]/1 http://eel.is/c++draft/concepts#concept.moveconstructible-1 ? Or does constructible_­from and convertible_­to guarantee these conditions hold?

I ran into some issues using the existing version:

• There's no 128 bit integral support, which I'd like to have in std::format, I can add a __u128toa to fix this.
• There's no direct support for wchar_t in std::to_chars.

In D70631#1781059, @STL_MSFT wrote:

@STL_MSFT How do you want to proceed with this? We can either back-and-forth on this review until we're happy and we can ship it (my preference),
or if you prefer someone from libc++ can take over the patch from here. My preference is clearly the former, but I want to avoid annoying you in case you don't have time for this.

I humbly request the latter (take over the patch) as I'm currently time-limited due to getting the microsoft/STL repo up and running for community contributions. As I'm not familiar with working in the libc++ environment, iterating with me in the loop will be extremely time-consuming for all involved. My hope is that, given that Jorg has gotten the code working on at least one libc++ platform, you can adapt the tests, and use them to verify that further changes for other platforms don't disrupt the code, which should make iterating on the code much faster.

I am, however, available to answer questions, review diffs to the code, or change microsoft/STL in ways that will make your life easier.

In D88131#2547168, @cjdb wrote:

In D88131#2545799, @ldionne wrote:

Are you using arc diff to upload patches? The Phab -> BuildKite bridge seems to have trouble applying your patches, not sure why.

No, I've been using the Phab web interface. Do you recommend I try the CLI tool instead?

Remove the C++11 comparibility again in filesystem_common.h. Tested with _LIBCPP_CONSTEXPR_AFTER_CXX11 which seems to work locally.

In D96200#2546962, @curdeius wrote:

Isn't it strange that a filesystem test builds the sources with -std=c++11? By source here I mean something under src/, precisely libcxx/src/filesystem/filesystem_common.h.
It seems like a bad separation between the code and the tests.

Partial revert, since one modification is still required for C++11.

Need to solve the the CI merge issue first.

Switch to MAKE_STRING instead of MKSTR, this should fix the filesystem build.

Rebase to trigger CI.