Skip to content
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

Enforce rust fmt #107

Merged
merged 18 commits into from
Jun 8, 2020
Merged

Enforce rust fmt #107

merged 18 commits into from
Jun 8, 2020

Conversation

almusil
Copy link
Contributor

@almusil almusil commented May 27, 2020

@hannobraun Can you please take a look?

@almusil almusil force-pushed the enforce_rust_fmt branch from db5f17d to ab7c448 Compare May 27, 2020 11:55
@dbrgn
Copy link
Contributor

dbrgn commented May 27, 2020

I'm definitely in favor of using and enforcing rustfmt everywhere.

Not sure whether this should be a single reformatting commit though. Is there any advantage in having multiple commits?

@almusil
Copy link
Contributor Author

almusil commented May 27, 2020

IMO it is better to keep the history what was actually done. But I don't mind squashing it into single commit.

@dbrgn
Copy link
Contributor

dbrgn commented May 27, 2020

I'm a big fan of keeping the history clean, but in "git log FILE" and "git blame FILE" both approaches will show up as a single commit 🙂 In contrast, I tend to find a single commit easier to "parse" in the commit history than 17. (The CI change makes sense as a separate commit though.)

In any case, no strong opinons on that. I do think enforcing rustfmt is a good idea though, it completely eliminates the opinionated "could you please format this part of the code in a different way" from PR reviews.

src/pwr.rs Outdated
// Use MSI as clock source after wake-up
w.stopwuck().clear_bit(),
// Use MSI as clock source after wake-up
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one looks a bit weird... Since when does rustfmt put opening curly braces on its their own line? Might be a mess-up due to the comment...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It probably is. I will rearrange the comment so it does not look that bad. Good catch thanks


// Configure Stop mode
self.pwr.0.cr.modify(|_, w|
self.pwr.0.cr.modify(|_, w| {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that I forgot to change this one. On it

@almusil almusil force-pushed the enforce_rust_fmt branch from ab7c448 to 98f901f Compare May 27, 2020 12:42
@hannobraun
Copy link
Contributor

Thank you, @almusil and @dbrgn! The formatting changes look good to me (well, as good as it gets with rustfmt'ed code, at least :-) ).

I see two minor problems with the last commit:

  1. I think formatting should not be enforced on nightly. I think that has lead to problems in the past in other projects, but I don't remember clearly why that was. Probably, nightly rustfmt tends to make different formatting choices than stable/beta, which means it's going to fail all the time anyway.
  2. It would be great if there was a script that was called by CI, that I could also run locally to figure out whether CI was likely to pass (example of this in another HAL). Otherwise, people are going to submit unformated code and won't even know right away, because CI takes a while to run and GitHub won't notify the PR author if it fails. This is going to lead to a lot of unnecessary back-and-forth.

I think it's fine to merge as-is though, and follow up with additional improvements later, as necessary. Especially point 2 is a bit of a can of worms of worms, due to the use of the build Matrix on CI (that other HAL I linked doesn't use the build Matrix for that reason).

@arkorobotics What do you think? I'm inclined to merge this, to get the formatting discussion over with.

@hannobraun
Copy link
Contributor

I've just introduced a conflict by merging #101.

@almusil, can you take a look?

@almusil
Copy link
Contributor Author

almusil commented May 27, 2020

@hannobraun Rebased, thanks

@almusil
Copy link
Contributor Author

almusil commented May 27, 2020

Thank you, @almusil and @dbrgn! The formatting changes look good to me (well, as good as it gets with rustfmt'ed code, at least :-) ).

I see two minor problems with the last commit:

1. I think formatting should not be enforced on nightly. I think that has lead to problems in the past in other projects, but I don't remember clearly why that was. Probably, nightly rustfmt tends to make different formatting choices than stable/beta, which means it's going to fail all the time anyway.

Rust fmt might enforce different rules on nightly and also fmt is not always available there. So it makes sense to skip fmt on nightly.

2. It would be great if there was a script that was called by CI, that I could also run locally to figure out whether CI was likely to pass ([example of this in another HAL](https://github.com/lpc-rs/lpc8xx-hal/blob/master/scripts/build.sh)). Otherwise, people are going to submit unformated code and won't even know right away, because CI takes a while to run and GitHub won't notify the PR author if it fails. This is going to lead to a lot of unnecessary back-and-forth.

This should not be that hard I will create a issue for that and assign myself. Once I have some more spare time I'll look into this.

I think it's fine to merge as-is though, and follow up with additional improvements later, as necessary. Especially point 2 is a bit of a can of worms of worms, due to the use of the build Matrix on CI (that other HAL I linked doesn't use the build Matrix for that reason).

@arkorobotics What do you think? I'm inclined to merge this, to get the formatting discussion over with.

@almusil
Copy link
Contributor Author

almusil commented Jun 7, 2020

Any update?

@dbrgn
Copy link
Contributor

dbrgn commented Jun 7, 2020

There's a new conflict, maybe you can resolve that?

Rust fmt might enforce different rules on nightly and also fmt is not always available there. So it makes sense to skip fmt on nightly.

I think this is still missing as well, right? Or would that be part of #109?

@almusil almusil force-pushed the enforce_rust_fmt branch from 341a99b to 5a744a4 Compare June 8, 2020 07:27
@almusil
Copy link
Contributor Author

almusil commented Jun 8, 2020

There's a new conflict, maybe you can resolve that?

Done

Rust fmt might enforce different rules on nightly and also fmt is not always available there. So it makes sense to skip fmt on nightly.

I think this is still missing as well, right? Or would that be part of #109?

It was meant to be part of #109 but I can probably do it in this patch. Only thing that might make it harder are the conflicts so if it's not vital I would rather do it in follow up.

@hannobraun
Copy link
Contributor

Nobody has complained, and this has been open long enough. I'm merging.

Thank you, @almusil!

@hannobraun hannobraun merged commit 489685c into stm32-rs:master Jun 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants