| 17 Jul 2025 |
 Alyssa Ross | Often the header something happens to be defined in for your platform isn't the one you should actually be including to be standards conformant and portable | 19:29:09 |
| Alyssa Ross | (If it's possible to exclude libc headers rthat would probably help) | 19:30:31 |
| 18 Jul 2025 |
 fzakaria | aren't we solving that with Nix ? | 02:45:02 |
| fzakaria | like... we own all the header up until glibc... there's nothing non-portable | 02:45:16 |
 emily | Nix runs on Linux and Darwin (and also to some extent FreeBSD, Windows, …) | 02:45:59 |
| 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 |
| Mic92 | Same actually for platform specific header - could be a bit tedious though | 17:35:25 |
| Mic92 | @xokdvium:matrix.org: clang format stuff is good to go? | 17:36:58 |
 Sergei Zimmerman (xokdvium) | I think so. The diff is good and the auto-rebase script seems to work well. | 17:37:33 |
| Mic92 | Okay. Hit it! | 17:38:04 |
| Sergei Zimmerman (xokdvium) | Done! No more range formatting. Yay! | 17:40:50 |
| Sergei Zimmerman (xokdvium) | Pinned an issue about the auto-rebase script: https://github.com/NixOS/nix/issues/13502 | 18:02:18 |
 connor (he/him) (UTC-7) | I know that one of the expensive parts of CI with Nix monorepos is evaluation on each commit in part because there's no re-use of evaluation caches across commits.
I see that a new AttrDb is created for each fingerprint (https://github.com/NixOS/nix/blob/b8d223a2106c7dbdb0c61f822288195ee9e26e9b/src/libexpr/eval-cache.cc#L75).
For those with knowledge about evaluation caching as it is currently implemented: would it be feasible to rewrite it such that entries in Attributes use the hash of their source files as part of their primary key?
As an example, if the hashes of the files read to evaluate an attribute doesn't change across two commits, the result from the first evaluation would be returned for the second (it would be cached). | 22:05:10 |
|  andiandi 🐈 changed their display name from andiandi 🦆 to andiandi@hadr25. | 22:09:06 |
| andiandi 🐈 changed their display name from andiandi@hadr25 to andiandi@hadr25 🏰🏞️. | 22:13:42 |
| 19 Jul 2025 |
 ma27 | In reply to @connorbaker:matrix.org
I know that one of the expensive parts of CI with Nix monorepos is evaluation on each commit in part because there's no re-use of evaluation caches across commits.
I see that a new AttrDb is created for each fingerprint (https://github.com/NixOS/nix/blob/b8d223a2106c7dbdb0c61f822288195ee9e26e9b/src/libexpr/eval-cache.cc#L75).
For those with knowledge about evaluation caching as it is currently implemented: would it be feasible to rewrite it such that entries in Attributes use the hash of their source files as part of their primary key?
As an example, if the hashes of the files read to evaluate an attribute doesn't change across two commits, the result from the first evaluation would be returned for the second (it would be cached). I think part of the problem is that you can't really say which files are the sourcefiles of an attribute without an evaluation, right? | 17:41:11 |
| 20 Jul 2025 |
| connor (he/him) (UTC-7) | I think you could if using the flake interface. I've lookged through the eval-cache.cc file a bit, here's an idea.
Consider the portion which involves getting the keys of an attribute set. If before and after forcing a value you were snapshot and then compare the results of the import cache, that could be a start. | 03:48:39 |
 roberth | I plan to work on that starting Sep/Oct. Might work regardless of flakes :: Bool | 15:16:39 |
 magic_rb | In reply to @ma27:nicht-so.sexy
I think part of the problem is that you can't really say which files are the sourcefiles of an attribute without an evaluation, right? Evaluation should form a tree of visited files theoretically. So you could go and rehash all the files and once you find the first divergence you need to reeval (if we could take incremental snapshots of the evaluator state and flatten the visited files into a list on the time axis, you could even pick up the eval maybe from where it left off? Essentially if you change only a leaf file, you only reimport the leaf) | 15:31:04 |
