[libc-commits] [libc] [libc] Revert https://github.com/llvm/llvm-project/pull/83199 since it broke Fuchsia. (PR #83374)

[via libc-commits]

lntue wrote:

> I'm sorry; this is probably [my fault](https://github.com/llvm/llvm-project/pull/83199#discussion_r1505134208) for suggesting we eliminate the extra `include` in all of our `#include` statements.
> 
> It would be good for @frobtech to comment _in public here_ but if I had to _guess_ what might be the issue:
> 
> Let's consider one header, for example [the change to libc/include/llvm-libc-types/float128.h](https://github.com/llvm/llvm-project/pull/83374/files#diff-c1878e8273656e499a8c281a236def689e508f294c0ad2c82a093dec59f72142). `""` include paths are relative to the file including them, so libc/include/llvm-libc-types/float128.h including `../llvm-libc-macros/float-macros.h` just worked. Removing `../` works if we add `-I libc/include/` for us...but now our downstream consumers of our external headers we provide now must also do the same. And the libc should not impose the requirement that you need multiple `-I` flags to use it (at least, it would be different if llvm-libc had that requirement).
> 
> I think that's what's going wrong. Either way, I'm sorry to have to back this out, since it did look like a nice cleanup to me otherwise. I guess that the `target_include_directories` rules needed to be added for the tests should have been a smoking gun in code review, and I'm sorry I didn't comprehend that during code review and is now resulting in more churn.

I've created https://github.com/llvm/llvm-project/issues/83463 to keep track of documentation and clang-tidy updates.

https://github.com/llvm/llvm-project/pull/83374