| 18 Jul 2025 |
 emily | so system header portability is still a concern (and has broken the build in the past) | 02:46:26 |
 fzakaria | aren't those controlled by IFDEF macros so it's still IWYU..
anyways I don't think 100% is necessary | 02:54:29 |
| fzakaria | but something more than today; I open any file and 1/2 of every include is either unused as per clangd or there's no include so it's difficult to follow the hierarchy | 02:54:53 |
| fzakaria | like aspirational | 02:55:01 |
| fzakaria | :) | 02:55:02 |
| fzakaria | I found this bug in Nix -- I sent a failing test case to capture it
https://github.com/NixOS/nix/pull/13456
Dunno if we like having test cases that validate the failure mode -- albeit easy to flip | 02:56:26 |
| emily | Alyssa means that including system headers can non-portably lead to the definition of a symbol that is only properly (portably) obtained by including a header that a standard specifies it's found in | 03:23:19 |
| emily | because of nested includes in the system headers etc. | 03:23:25 |
| emily | at least a naive "redundant include checker" would complain about including both such headers, even if it is the correct thing for portability across platforms | 03:23:59 |
| fzakaria | sure; still better than current model. You can special case the 10% rather than give up on the 90% | 15:08:38 |
 Mic92 | In reply to @fzakaria:one.ems.host
sweet -- the IWYU is what i'm really after. You mean the clang-tidy one? Works quite well on nix-eval-jobs | 17:33:14 |
| Mic92 | In reply to @qyliss:fairydust.space
IWYU is difficult for portable programs like Nix Maybe that can be enabled somehow for nix header only? | 17:34:34 |
