dani-garcia / vaultwarden

Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs
GNU Affero General Public License v3.0
36.98k stars 1.8k forks source link

Rust 2024 breaking changes #4974

Open zacknewman opened 2 hours ago

zacknewman commented 2 hours ago

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.

zacknewman commented 2 hours ago

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.

dani-garcia commented 1 hour ago

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

zacknewman commented 1 hour ago

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 52 minutes ago

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.