Edition 2024, Rust v1.96, Deps upgraded to latest (locked to x.y), Unmaintained knuffel replaced with knus

[takashialpha]

hiii, here's everything in this PR:

• bumped to Edition 2024: this mostly required wrapping env usage in unsafe.
• bumped the Rust version to v1.96.
• replaced the unmaintained knuffel crate with knus: this mostly required renaming knuffel references throughout the codebase. As a bonus, this lets us pull in the latest miette.
• ran fmt as recommended by the contributing guide. All tests pass, and clippy runs with 0 (no) warnings.
• tried bumping accesskit and accesskit_unix as well, but left them as-is (the only dependencies not on their latest versions), since the corresponding issue (Screen reader doesn't announce anything from niri #3594) doesn't seem to have a solution other than downgrading.** updates below

[takashialpha]

As a Niri user, I also replaced the previous binary I was using with the one from this PR, and everything has been running smoothly so far. I'll continue using it and will report back if I find any problems.

Update: Smooth 😃

[takashialpha]

Actually, we WILL be able to bump accesskit and accesskit_unix to latest, when accesskit_unix v0.21.2 comes out. That release will include the fix for the issue #3594.

[YaLTeR]

That's good to hear. FWIW, I'm not sure I'll be accepting this PR:

• I'd like to bump to edition 2024 myself because 1. I need to review some other PRs first to avoid massive conflicts and 2. When I tried doing it recently, there were a bunch of nonobvious spots where it was easy to accidentally change behavior, and I want to inspect all of them.
• We're not bumping MSRV unnecessarily, certainly not to the current newest version.
• Updating knuffel to knus has potential for config breakage (that I don't see addressed in any way), yet there's barely any benefit to doing it. Knuffel works perfectly fine until we maybe move to smth else entirely.

[takashialpha]

Thanks for the feedback. I went back and checked the knus changes in more detail.

knus 3.2.0 is effectively identical to knuffel 3.2.0, which niri already uses. The changes in knus 3.3.x are fairly small: a few AST fields became public, parse_* now accepts impl AsRef<str>, there's a derive macro hygiene fix, some extra trait derives, and an upgrade to miette 7.6. As far as I can tell, none of those affect the KDL decoding logic or how config.kdl is interpreted; the most visible change is improved error rendering.

If I've missed something, I'm happy to be corrected, but based on the documented diff I don't see much breakage risk from the knus switch itself.

I'm going to leave the PR as-is rather than split it up, so feel free to review whichever parts make sense when you have time. If it helps, I can point you to the places that may be affected by the Rust 2024 temporary drop order changes.

One thing I'm curious about: you mentioned possibly moving away from knuffel/knus entirely in the future. Do you have a specific alternative in mind, such as native serde support in kdl-rs, facet, or something else? That would help me understand where you'd prefer config-parsing effort to go.

[YaLTeR]

knus 3.2.0 is effectively identical to knuffel 3.2.0, which niri already uses. The changes in knus 3.3.x are fairly small: a few AST fields became public, parse_* now accepts impl AsRef<str>, there's a derive macro hygiene fix, some extra trait derives, and an upgrade to miette 7.6. As far as I can tell, none of those affect the KDL decoding logic or how config.kdl is interpreted; the most visible change is improved error rendering.

That's good to know, I'll keep it in mind. But well, we have no problems with knuffel (other than miette version, but that only becomes a problem if we add a new one in the dep tree). If anything, the fact that this config parsing code doesn't change is good because it means no possibility for accidental breakage.

One thing I'm curious about: you mentioned possibly moving away from knuffel/knus entirely in the future. Do you have a specific alternative in mind, such as native serde support in kdl-rs, facet, or something else? That would help me understand where you'd prefer config-parsing effort to go.

I've been thinking about different approaches (among the ones you mentioned, plus maybe hand-rolling something), but I have no concrete plan. It's a big chunk of work either way. It's not pressing and I'm not sure when/if I can get around to it (plenty of more important PRs to deal with first).