-
Notifications
You must be signed in to change notification settings - Fork 928
rustfmt_lib = { git = "https://github.com/rust-lang/rustfmt" } #4388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It would be nice to be able to work from git. An alternative would be to publish a Current error with
|
If you're going to try to build from source, make sure to adjust the references to the latest in source (https://github.com/rust-lang/rustfmt/blob/master/Cargo.toml#L3) as some things were restructured a bit since the previous tag.
I don't think you're working with the latest in source. Perhaps you need to run a
Sorry, but I don't want to get in the habit of having to publish tags to support git based consumption. To be honest, I'm not sure that making rustfmt available as a lib for outside consumers will be part of the strategy going forward, particularly with git-based references. The auto publish process for consuming rustc internals is already challenging enough within rustfmt itself, and I don't want to put more work on the rustfmt plate. |
It is super useful to be able to format from a wasm/wasi libary. You can't run external processes such as rustfmt from wasi. Please keep this as a use case.
I would prefer to use a published version, rather than git. I first tried to use the 2.0.0-rc.2 published binary, but it did not work. It gave me the errors I posted above, because it is using the older rustc-ap-* crates. Is
Here is the code I'm using. If there is an easier way, please let me know. Thank you a lot for your rustfmt contributions! fn format_code(unformatted: String) -> String {
let mut config = rustfmt_nightly::Config::default();
config.set().edition(rustfmt_nightly::Edition::Edition2018);
config.set().max_width(140);
let setting = rustfmt_nightly::OperationSetting {
verbosity: rustfmt_nightly::emitter::Verbosity::Quiet,
..rustfmt_nightly::OperationSetting::default()
};
match rustfmt_nightly::format(rustfmt_nightly::Input::Text(unformatted.clone()), &config, setting){
Ok(report) => {
match report.format_result().next() {
Some((_, format_result)) => {
let formatted = format_result.formatted_text();
if formatted.is_empty() {
unformatted
} else {
formatted.to_owned()
}
}
_ => unformatted
}
}
Err(_err) => {
unformatted
}
}
} |
Yup, exactly.
I know there's a handful of crates out on crates.io from some experimental things several months ago, but the only official rustfmt crate is https://crates.io/crates/rustfmt-nightly. v2.0 has not been officially published and that's very much be design.
No decisions have been made yet, but the rustc auto publish process is the inherent problem here. rustfmt is deeply reliant on the rustc internals, and in order to be able to publish rustfmt to crates.io, those rustc internals have to be consumed via the auto publish process (the rustc-ap crates). This approach has some notable downsides, primarily that breaking rustc changes are regularly merged upstream which breaks rustfmt and makes rustfmt unavailable for long periods of time through any medium, including rustup. It's not that we don't see value in rustfmt being available as a lib, but with the current dependencies on rustc internals, it is a question of tradeoffs and whether it's worth continuing to have long bouts of rustfmt not being available for anyone just to support a handful of rustfmt-as-a-lib use cases. |
In
Cargo.toml
, I haveBut that version does not compile and I'd like to update to the latest
2.0.0
code, but this does not work:The text was updated successfully, but these errors were encountered: