Rust 2024 breaking changes #5673

New Issue

GiteaMirror · 2026-03-07T20:34:30-06:00

GiteaMirror commented

2026-03-07 20:34:30 -06:00

Originally created by @zacknewman on GitHub (Sep 20, 2024).

Vaultwarden Support String

N/A

Vaultwarden Build Version

N/A

Deployment method

Build from source

Custom deployment method

No response

Reverse Proxy

N/A

Host/Server Operating System

Other

Operating System Version

No response

Clients

Web Vault

Client Version

No response

Steps To Reproduce

Add rust-2024-compatibility to the list of deny lints and compile code. One error is caused by some of the macro definitions. For example, crate::error::make_error doesn't compile due to "the expr fragment specifier will accept more expressions in the 2024 edition".

Expected Result

Compilation to succeed.

Actual Result

Compilation failure.

Logs

No response

Screenshots or Videos

No response

Additional Context

See the Migration Guide for how to fix this.

Originally created by @zacknewman on GitHub (Sep 20, 2024). ### Vaultwarden Support String N/A ### Vaultwarden Build Version N/A ### Deployment method Build from source ### Custom deployment method _No response_ ### Reverse Proxy N/A ### Host/Server Operating System Other ### Operating System Version _No response_ ### Clients Web Vault ### Client Version _No response_ ### Steps To Reproduce Add `rust-2024-compatibility` to the list of `deny` lints and compile code. One error is caused by some of the macro definitions. For example, `crate::error::make_error` doesn't compile due to "the `expr` fragment specifier will accept more expressions in the 2024 edition". ### Expected Result Compilation to succeed. ### Actual Result Compilation failure. ### Logs _No response_ ### Screenshots or Videos _No response_ ### Additional Context See [the Migration Guide](https://doc.rust-lang.org/nightly/edition-guide/rust-2024/macro-fragment-specifiers.html) for how to fix this.

GiteaMirror added the bug label 2026-03-07 20:34:30 -06:00

GiteaMirror closed this issue

2026-03-07 20:34:30 -06:00

GiteaMirror commented

2026-03-07 20:34:31 -06:00

@zacknewman commented on GitHub (Sep 20, 2024):

I realize this is not a bug per se; but seeing how Vaultwarden stays up-to-date with Rust and its libraries, it's reasonable to assume that when 2024 is released (ETA is 02/2025), this will cause issues. Might as well address them when you can.

@zacknewman commented on GitHub (Sep 20, 2024): I realize this is not a bug per se; but seeing how Vaultwarden stays up-to-date with Rust and its libraries, it's reasonable to assume that when 2024 is released (ETA is 02/2025), this will cause issues. Might as well address them when you can.

GiteaMirror commented

2026-03-07 20:34:32 -06:00

@dani-garcia commented on GitHub (Sep 20, 2024):

I don't think the expr fragment change is something that needs action from our side, as the change only means that in edition 2024 expr will also capture const and _ expressions, while it previously didn't do so, and as far as I can see all our uses of expr should be safe as we never match against const or _, so the macro rules parsing should be unaffected for our usecases.

That said while checking cargo +nightly fix --edition I noticed that we're using the gen keyword in the macros, which is going to be reserved in 2024, so I've changed that: https://github.com/dani-garcia/vaultwarden/pull/4975

@dani-garcia commented on GitHub (Sep 20, 2024): I don't think the `expr` fragment change is something that needs action from our side, as the change only means that in edition 2024 `expr` will also capture `const` and `_` expressions, while it previously didn't do so, and as far as I can see all our uses of `expr` should be safe as we never match against `const` or `_`, so the macro rules parsing should be unaffected for our usecases. That said while checking `cargo +nightly fix --edition` I noticed that we're using the `gen` keyword in the macros, which is going to be reserved in 2024, so I've changed that: https://github.com/dani-garcia/vaultwarden/pull/4975

GiteaMirror commented

2026-03-07 20:34:32 -06:00

@zacknewman commented on GitHub (Sep 20, 2024):

I wasn’t claiming the macro is wrong; however, if/when the lint is added to the list of deny lints like the 2021 lint is, then compilation will fail. So you will at least have to allow that lint individually for the macros. Perhaps there is no intention in adding that lint to the deny list; but seeing how 2021 is added, I assumed 2024 will be too.On Sep 20, 2024, at 12:37 PM, Daniel García @.***> wrote:
I don't think the expr fragment change is something that needs action from our side, as the change only means that in edition 2024 expr will also capture const and _ expressions, while it previously didn't do so, and as far as I can see all our uses of expr should be safe as we never match against const or _, so the macro rules parsing should be unaffected for our usecases.
That said while checking cargo +nightly fix --edition I noticed that we're using the gen keyword in the macros, which is going to be reserved in 2024, so I've changed that: #4975

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

@zacknewman commented on GitHub (Sep 20, 2024): I wasn’t claiming the macro is wrong; however, if/when the lint is added to the list of deny lints like the 2021 lint is, then compilation will fail. So you will at least have to allow that lint individually for the macros. Perhaps there is no intention in adding that lint to the deny list; but seeing how 2021 is added, I assumed 2024 will be too.On Sep 20, 2024, at 12:37 PM, Daniel García ***@***.***> wrote: I don't think the expr fragment change is something that needs action from our side, as the change only means that in edition 2024 expr will also capture const and _ expressions, while it previously didn't do so, and as far as I can see all our uses of expr should be safe as we never match against const or _, so the macro rules parsing should be unaffected for our usecases. That said while checking cargo +nightly fix --edition I noticed that we're using the gen keyword in the macros, which is going to be reserved in 2024, so I've changed that: #4975 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

GiteaMirror commented

2026-03-07 20:34:33 -06:00

@zacknewman commented on GitHub (Sep 20, 2024):

By the way, I think you should be able to run cargo fix --edition on stable/1.81. Not that matters; but if the reason for not adding rust-2024-compatibility is the idea only nightly can use it, then that's not the case.

@zacknewman commented on GitHub (Sep 20, 2024): By the way, I think you should be able to run `cargo fix --edition` on stable/1.81. Not that matters; but if the reason for not adding `rust-2024-compatibility` is the idea only nightly can use it, then that's not the case.

GiteaMirror commented

2026-03-07 20:34:33 -06:00

@zacknewman commented on GitHub (Sep 20, 2024):

I'll let you all close this when desired. It probably makes sense to add rust-2024-compatibility to the list of deny lints sooner than later that way new code changes that would cause issues are prevented; however that's only if the plan is to change editions. Perhaps making this a discussion instead makes sense that way it can still be "tracked".

@zacknewman commented on GitHub (Sep 20, 2024): I'll let you all close this when desired. It probably makes sense to add `rust-2024-compatibility` to the list of `deny` lints sooner than later that way new code changes that would cause issues are prevented; however that's only if the plan is to change editions. Perhaps making this a discussion instead makes sense that way it can still be "tracked".

GiteaMirror commented

2026-03-07 20:34:34 -06:00

@BlackDex commented on GitHub (Sep 21, 2024):

We could add this:

rust_2024_compatibility = { level = "deny", priority = -1 }
edition_2024_expr_fragment_specifier = "allow"

That would not alert on those maybe to be changed macro's but still warn/deny about all other future items.

@BlackDex commented on GitHub (Sep 21, 2024): We could add this: ```toml rust_2024_compatibility = { level = "deny", priority = -1 } edition_2024_expr_fragment_specifier = "allow" ``` That would not alert on those maybe to be changed macro's but still warn/deny about all other future items.

GiteaMirror commented

2026-03-07 20:34:35 -06:00

@zacknewman commented on GitHub (Sep 21, 2024):

rust_2024_compatibility = { level = "deny", priority = -1 }
edition_2024_expr_fragment_specifier = "allow"

Personally, I prefer to expect lints on a case-by-case basis that way I don't unintentionally let something go through. As the error shows, the semantics of macros can be changed; so it's possible that a macro is not correct or a new macro is not correct; however by globally allowing/expecting it, you may let something through that shouldn't be. It's currently not stable, but eventually one should be able to use expr_2021 to ensure 2021 and prior semantics is retained.

Of course so long as new macros are written with the 2024 semantics and all existing macros are not affected, then it makes sense to just globally expect/allow it.

@zacknewman commented on GitHub (Sep 21, 2024): > ```toml > rust_2024_compatibility = { level = "deny", priority = -1 } > edition_2024_expr_fragment_specifier = "allow" > ``` Personally, I prefer to `expect` lints on a case-by-case basis that way I don't unintentionally let something go through. As the error shows, the semantics of macros can be changed; so it's _possible_ that a macro is not correct or a new macro is not correct; however by globally `allow`ing/`expect`ing it, you may let something through that shouldn't be. It's currently not stable, but eventually one should be able to use [`expr_2021`](https://doc.rust-lang.org/nightly/edition-guide/rust-2024/macro-fragment-specifiers.html) to ensure 2021 and prior semantics is retained. Of course so long as new macros are written with the 2024 semantics and all existing macros are not affected, then it makes sense to just globally `expect`/`allow` it.