| 28 Oct 2025 |
 @dawnofmidnight:catgirl.cloud | * yeah, pretty much. differences in behavior are almost always either a bug (in rust itself) or a fix (which you'll get in a few weeks on stable, and you probably want) | 22:31:39 |
| @dawnofmidnight:catgirl.cloud | * yeah, pretty much. differences in behavior are almost always either a bug (in rust itself) or a fix (which you'll get in a few weeks on stable, and you probably want)
(obviously this no longer holds true when you opt into unstable features with #![feature(...)] or -Z and such, but this is true for already-stable things) | 22:34:04 |
 crop | thank you for clarifying | 22:39:09 |
| 29 Oct 2025 |
| crop | I switched to fenix with complete toolchain. The problem is that rustfmt (or whatever is the default for formatting) somehow doesn't recognize that the project is written in edition 2024. It fails with an error something along the line "let chains only supported in edition 2024". | 11:38:45 |
| crop | The editor i use is helix | 11:39:13 |
 Charles | what's your rustfmt.toml say | 14:41:13 |
| crop | I don't have one in the project. Are there other places where i should look? | 17:10:20 |
 antifuchs | Make sure which rustfmt doesn’t pick up an older rustup installation? | 17:21:22 |
| Charles | that might be your problem. i'm not sure if rustup cares to read Cargo.toml to figure out the edition | 18:49:07 |
| Charles | you do at least have the edition set properly in Cargo.toml, yeah? | 18:49:56 |
| Charles | * that might be your problem. i'm not sure if rustfmt cares to read Cargo.toml to figure out the edition | 18:50:52 |
| 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 |
