Looks good for my comments.

In D67867#1684296, @MaskRay wrote:

In D67867#1683099, @sivachandra wrote:

In D67867#1682894, @jyknight wrote:

I think one directory per function is going to be annoying, not helpful. Most libc functions are expressible as a single function of less than 100 LOC. I'd suggest, instead, to have e.g. src/stdlib/strcpy.cc, implementing the strcpy function. It seems like a good rule that every file implements one public function. If additional files are needed for implementation clarity, I'd suggest to put such helper code into something like src/stdlib/internal/strcpy_internal.cpp (obviously not _actually_ for strcpy)

My choice here is driven by my preference to keep tests co-located with the implementation. Since we are in general going to have different kinds of testing like unit-testing, differential testing, fuzz-testing, I have chosen to put implementations of individual functions in their own directories. This way, the tests (which will span multiple files) will all be in a single directory and avoid clutter in the higher level directory. In the rare occasion that implementation also spans multiple files, all the implementation files will also live together.

Some tests will involve several functions from a header, e.g. flockfile+ftrylock+funlockfile. Where will you place the test, under flockfile/, or funlockfile/ ?

I prefer jyknight's proposed hierarchy.

Remove superfluous SSL context, add retries on closed connection, and attach a comment to revision updates.

Alright, here's what's changed:

After a quick once-over, I do have a few nit-picky comments. I plan to do another pass, but these are some things that were a little bit surprising up front.

In D67747#1674975, @lebedev.ri wrote:

Why reimplement the wheel?
Does arc diff --update not work with git monorepo?

A basic start! This managed to upload itself and create the differential revision.

No-op update

FYI: reverted in r368800.

FYI: reverted in r368800.

FYI: reverted in r368800.

This change (along with the subsequent fixes) seems to cause a stage3 clang to miscompile itself when using an FDO profile and Thin LTO (i.e., using stage2 Clang built with FDO and ThinLTO to rebuild itself yields non-deterministic output). The failure is still present past r368596, so that revision did not fix whatever issue I'm seeing.

(Wall of text warning... sorry!)

Run gn format

In D61819#1500150, @thakis wrote:

Like with the Lanai target: lgtm with the usual two comments (1. https://reviews.llvm.org/D61859 treatment for MCTargetDesc;

https://reviews.llvm.org/rG500a6db47951521cbe4b3d23976aa4b790085019

In D61818#1500147, @thakis wrote:

lgtm with the usual two comments (1. https://reviews.llvm.org/D61859 treatment for MCTargetDesc;

Ah, this makes sense. I had missed the distinction on the :tablegen targets.

Yup, that's why I worded the message the way I did.