| 29 Oct 2025 |
 Charles | maybe it does if you cargo fmt but not if you rustfmt, you could try both and see what happens and then check how helix is invoking the formatter | 18:51:26 |
 crop | Yes. I have all the expected binaries. And a cargo toml with edition 2024. And rustfmt print-config shows the wrong edition. But because i kept working it doesn't fail anymore | 18:51:49 |
| crop | Cargo fmt as well | 18:52:20 |
| crop | At least i know now what i should configure if i run into the problem again. Should not be nix specific | 18:53:18 |
| 30 Oct 2025 |
|  QuadRadical (Ping) changed their profile picture. | 19:10:31 |
| 31 Oct 2025 |
|  Theo Paris joined the room. | 01:55:33 |
|  uie joined the room. | 11:57:33 |
| 1 Nov 2025 |
|  Acid Bong joined the room. | 07:48:39 |
|  Ihar Hrachyshka joined the room. | 16:31:08 |
| Ihar Hrachyshka | for firefox (darwin) I need a llvmPackage_20 flavor of rust (rustc, cargo...). Here is what I have: https://github.com/NixOS/nixpkgs/pull/457369/commits/ba137568714c20347f22038516307906a5da7bce it works but doesn't look pretty. Is there an easier / better way to get pure 20 stack? | 16:32:08 |
| Ihar Hrachyshka | (not sure I need all of these overrides, but definitely some are needed, otherwise I have rustc referring to both 20 and 21 and LTO builds failing due to mixed versions) | 16:33:15 |
 emily | the Rust derivation could probably rely on splicing instead of pkgsFooBar for those, but is there no way to turn off optimization flags or such to fix the LLVM 21 miscompilation instead? | 16:51:25 |
| emily | or if the cause of the miscompilation is known we could revert the commit as a patch? | 16:51:39 |
| Ihar Hrachyshka | oh but I mean I want to enable LTO :) this is in the way. otherwise it compiles fine. | 16:55:07 |
| Ihar Hrachyshka | as-is firefox is "fine" - as in it compiles and works. only when LTO is enabled, the linker can't find some symbols for reasons. that's where I figured it's because llvm versions mixed for parts of the build - confirmed by looking at the tree of deps and the fix. | 16:56:49 |
| Ihar Hrachyshka | (the reason why we need llvm 20 has nothing to do with LTO per se - we found a bug in llvm 21 with firefox on aarch64-darwin and had to revert to 20 for now) | 16:59:16 |
| Ihar Hrachyshka | * (the reason why we need llvm 20 has nothing to do with LTO per se - we found a bug in llvm 21 with firefox on aarch64-darwin and had to revert to 20 for now) | 17:01:41 |
| emily | yes, I know | 17:06:54 |
| emily | I'm saying maybe you can just stay on the happy path of using LLVM 21 if you work around the bug or we revert its cause locally | 17:07:07 |
| Ihar Hrachyshka | oh if I were to know the cause... | 17:07:38 |
| Ihar Hrachyshka | for now I'm just waiting for mozilla folks who are now looking into it to come back with a fix. then we will probably know if we have a path with llvm21. | 17:08:20 |
| emily | have you tried bisecting? shouldn't take too long | 17:08:47 |
| Ihar Hrachyshka | bisecting whom? llvm? | 17:08:57 |
| emily | yeah | 17:09:38 |
| emily | we have a known good and known bad version | 17:09:45 |
| Ihar Hrachyshka | I am not sure about "shouldn't take too long" :D but maybe I'm missing something. AFAIU it means rebuilding the world a bunch of times. | 17:10:25 |
| emily | not the world. just LLVM, Rust, Firefox | 17:10:33 |
| emily | which sure, take a long time, but bisect is O(log n). | 17:10:41 |
| emily | so if you've built a handful of Firefoxes already you're well on the way to the total time it'd take to just find the problematic commit. | 17:10:54 |
| emily | which is going to be required for any long-term solution | 17:11:00 |
