Initiate configuration of rustfmt #374
Conversation
tcharding
force-pushed
the
rustfmt
branch
3 times, most recently
from
16a867d
to
dfc3e76
Compare
|
Changes in force push:
|
|
Will require manual configuration of the CI pipeline in order to merge. |
|
Rebased. |
tcharding
force-pushed
the
rustfmt
branch
3 times, most recently
from
ebcd453
to
49a08bd
Compare
tcharding
force-pushed
the
rustfmt
branch
2 times, most recently
from
2034c17
to
8e02ed0
Compare
|
Rebased and re-did the second two patches i.e., for each, updated the config option, ran |
|
There are merge conflicts here. This would need a rebase again :( |
We only run the formatter (`cargo fmt`) not the linter (`cargo clippy`). Use the appropriate term in the test script and the CI configuration.
|
Changes in force push:
|
Can you elaborate? Do you mean this would need to be merged in god mode? |
I don't know what setting has to be changed, I don't have access to settings so I'm going off what was said on another PR/repo when I changed the CI workflow. When a PR changes a workflow job the old one seems to still appear in the checks list on the web interface and the new one does not. Sorry I'm not very knowledgeable with GitHub. |
|
I think there is a bug in current config? See https://github.com/rust-bitcoin/rust-miniscript/actions/runs/2303431754
I can set the changes, but I cannot see the options for the fuzz-names in the CI workflow for this PR. Perhaps it is related to the above issue? |
Running `rustfmt` with the nightly toolchain allows us to use unstable options. Users can still run it with the stable toolchain locally and ignore the warnings.
Generate and add a default configuration file for `rustfmt` using rustfmt --print-config default rustfmt.toml This produces a config file that causes `rustfmt` to make no changes, as expected, when we run cargo +nightly fmt Please note, the config file includes unstable options which throw warnings if used without the nightly toolchain.
Configure `group_imports = "StdExternalCrate"`. The benefit of this option is that it increases uniformity in the code base over the default "Preserve", while saving devs needing to think about where they place their import statements (for those that do not use tooling to add them).
Configure `imports_granularity = "Module"`. The benefit of this option is that it increases uniformity in the code base over the default "Preserve" and also, from my personal experience, it tends to reduce the noise in diffs from adding/removing imports.
|
Well done, you were correct. Was missing a |
We currently use
rustfmtwith the default configuration. There is some interest in usingrustfmtin the crates lower down the stack but it is contentious and difficult to find a configuration, if one exists, that is 'good' for everyone. By configuringrustfmtin this crate we can reduce the scope of the discussion from 'should we even do this' down to 'this is a good formatting configuration', with the hope that if we can get a good configuration worked out in this crate it will help ease the debate in the others.To get this started add a default config file and then set two, hopefully non-contentious, config options.
Please note carefully; the first patch changes CI to run linting checks using the nightly toolchain.
Re: edition 2018 changes, there are some changes to imports in the
examples/that appear in this PR that should really be removed altogether, leaving as is so as not to clutter this PR.