[libc-commits] [libc] [libc] fix lint warnings from including <fenv.h> (PR #82695)

[Roland McGrath via libc-commits]

frobtech wrote:

I think we need to double-check that this is doing the right thing for cases like Fuchsia. The same might apply to the "overlay mode" builds too. In Fuchsia, we're using the llvm-libc sources, but entirely our legacy public API headers for the types users are really using. I think it may well be that `fenv_t` et al are defined with a per-arch ABI that's consistent for each arch across the legacy headers (both Fuchsia's and Linux cases like glibc, musl) and the llvm-libc implementation's internal and public API headers. It doesn't so much matter if the member names and internal structure of what is in embedded struct members or not and so forth matches between the API users are compiling against and the API llvm-libc code is compiling against, but it's crucial that the ABIs match. So while I think it might happen to be the case that it can be fudged in the case of `<fenv.h>` types and constants, that's not true in the general case. So to avoid any slippery slopes towards cases that are actually incorrect, we need to make sure that our style/lint rules are keeping us consistent with what's pedantically correct in all cases. That is, in the Fuchsia build or in "overlay mode" builds, we need to have the type definitions coming from the legacy system headers rather than from llvm-libc's headers.  Now it could be that the right way to achieve that is to have the implementation and test code always use llvm-libc internal header paths of a certain sort, and then each of those headers is doing the right thing to use either a system header or an llvm-libc-supplied header depending on the build situation. Maybe that's even already the way it works. But we need to be sure before applying this kind of "correctness" change.

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