You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.
At the moment we only respect Rustfmt file configuration, however it'd be good to also detect crate kind edition if specified in a Cargo.toml and use that as a default.
Not sure if I'm overthinking this, but it seems it's possible to have two distinct crate targets (e.g. [[bin]]) using a different edition but still including the same file - in this case the edition-specific formatting would be ambiguous. What does cargo fmt do in this case? I believe Cargo should try to detect that and possibly emit a warning since this could result in some subtle bugs or unexpected behaviour, while RLS should fail and with a message.
While we have the file -> package mapping thanks to project model, since the edition can be specified per crate target we'd need to resolve that information in a more fine-grained way. One way would be to parse the Cargo-emitted .d files for bin and libs or use something like build plan with computed file inputs to create a file -> [crate target] mapping.
The way I implemented it in cargo fmt is splitting the targets per edition settings and calling rustfmt with the respective --edition flag passed as argument.
The cargo_metadata crate already offers a convenient access to this information, what I did on rustfmt was basically make use of it.
At the moment we only respect Rustfmt file configuration, however it'd be good to also detect crate kind edition if specified in a Cargo.toml and use that as a default.
Not sure if I'm overthinking this, but it seems it's possible to have two distinct crate targets (e.g.
[[bin]]
) using a different edition but still including the same file - in this case the edition-specific formatting would be ambiguous. What doescargo fmt
do in this case? I believe Cargo should try to detect that and possibly emit a warning since this could result in some subtle bugs or unexpected behaviour, while RLS should fail and with a message.While we have the file -> package mapping thanks to project model, since the edition can be specified per crate target we'd need to resolve that information in a more fine-grained way. One way would be to parse the Cargo-emitted
.d
files for bin and libs or use something like build plan with computed file inputs to create a file -> [crate target] mapping.cc @otavio
The text was updated successfully, but these errors were encountered: