I continue to accept this. But, I missed some obvious things previously so, wait for @abrachet to take a look as well.
One thing though, this change is now wider than the original description. So, update the description here (and also in your local git repo if you use git llvm push.)

In D77533#1964606, @abrachet wrote:

Also, although we only want header files to have the C++ tag, shouldn't we also left justify the text in our .cpp files too?

This patch largely looks good, but I have a question inline.

Couple of nits inline but LGTM.

Looking at this now.

This change implements the topic I brought up many weeks ago: http://lists.llvm.org/pipermail/libc-dev/2020-January/000038.html.

Fix typos.

In D76967#1947538, @sivachandra wrote:

In D76967#1947520, @MaskRay wrote:

Delete all occurrences of __llvm_libc.

We made a decision to start with this, so we will stick with it unless we find some absolutely no go situation.

In D76967#1947520, @MaskRay wrote:

Delete all occurrences of __llvm_libc.

In D76825#1945462, @PaulkaToast wrote:

Won't deleting the files in the AOR directory cause the make check on the buildbots to fail? It might make sense to leave the files and delete them once all functions have been migrated?

In D76825#1944581, @sivachandra wrote:

In D76825#1942971, @abrachet wrote:

It's probably worth discussing how much we expect we will alter these files. Is it fine to just accept that we didn't write them and that they will just be very different from the rest of libc?

While I do intend to make any functional changes in this move patch, we absolutely want the code to follow our implementation standards, just like the rest of the code. So, thanks for already pointing out the items missed. For now, all I have done was to run clang-format. I will fix the rest with a new upload.

In D76825#1942971, @abrachet wrote:

It's probably worth discussing how much we expect we will alter these files. Is it fine to just accept that we didn't write them and that they will just be very different from the rest of libc?

This patch is not ready for review yet. For one, it does not have any tests. I am only sharing to showcase the move early.

This is another part I broke off from my sinf/cosf patch.

• Remove a leftover if block in add_loader_test.
• Add warning in the add_loader_test rule if the host is not unix.

Instead of this narrow check, what we really want is a check to ensure that all implementation detail resides in the namespace __llvm_libc. Anything outside would be special and requiring a NOLINT... for them is reasonable. Have you considered such an approach?

• Add "" arg to __builtin_nanf.
• Remove cosf and sinf from linux API; will add them in the patch adding their implementation.

Sorry it took me this long to comment here. Part of it was because I had to educate myself about mutli-byte characters and wide characters. Few high level questions:

OK with one naming fix suggested inline.

This is OK as a start. But, can we follow up with a study on running clang-tidy as part of our build rules? Like, what are the pros and cons? For the pros, I can think of:

Use -ffreestanding instead of -w.

In D76412#1932339, @MaskRay wrote:

The directory structure libc/loader/linux/x86_64/ does not seem very right. A loader can be made architecture agnostic with a little abstraction. I am concerned this will get copied over to x86 and aarch64.

Remove incorrect/redundant target_compile_options.

In D76412#1930707, @abrachet wrote:

Looks pretty good I think. It fails to link when using sanitizers though, they don't go well with -static I think.

• Do not run loader tests as part of check-libc as they are not yet sanitizer ready.
• Use add_executable with -nostdlib flag instead of calling the linker directly.

• Fix a typo in a test
• Add two more tests

In D74397#1929348, @gchatelet wrote:

Thank you @sivachandra and @abrachet for the review.
I'll submit it as-is for now and we can iterate from here.

In D76271#1926018, @abrachet wrote:

Could you show how you are using this? I have tried like:

add_object(
  special
  SRC
    special.cpp
  COMPILE_OPTIONS
    -Wframe-larger-than=0
)

add_entrypoint_object(
  entrypoint
  SRCS
    entrypoint.cpp
  HDRS
     entrypoint.h
  DEPENDS
     special
)

Doesn't work, entrypoint doesn't link against special.o

I just uploaded https://reviews.llvm.org/D76271. I tested it with this patch to make sure it is working as expected.

I think what is outstanding wrt comments is very minor. So, feel free to land and we can iterate if required after landing.

LGTM. I will write back before the end of today about the single object rule.

Sorry for the long delay here. I am feeling much better now and should be more responsive.

Ah sorry, this completely slipped from my radar. I am currently sick, but will try get to this before the end of this week.