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.

Sign up for GitHub

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

Jump to bottom

Prepare v0.7.4 #375

Merged
merged 5 commits into from
Jan 2, 2022
Merged

Prepare v0.7.4 #375

merged 5 commits into from
Jan 2, 2022

Conversation

adamgreig
Copy link
Member

I've created a new branch, v0.7.x, which is currently at the latest non-breaking commit (so includes #346 #349 #347 #351 #339 #352 #348 #363 #362 #361 but does not include #342), to track the 0.7 series since master now contains breaking changes for v0.8.

This PR (which targets the new branch) cherry-picks #372 #369 #374 and bumps the version to v0.7.4 (and updates CHANGELOG) ready for a new v0.7.4 release. Once complete I'll also backport the changelog entries and bump the version in master to 0.7.4.

I think this is everything that should be in 0.7 -- the only excluded PRs from master are #342 and #367 I believe, and I don't think we have any open PRs targeting 0.7 either.

Any other thoughts on items for inclusion in 0.7.4 (or other changelog entries I missed)?

bors bot and others added 4 commits December 31, 2021 17:22
@bors @jordens @adamgreig
Merge #372
9631347 
372: asm/inline: explicitly use asm macro r=adamgreig a=jordens

`asm!()` removed from prelude in current nightly
rust-lang/rust#91728

close #371

This is also a good candidate for the cortex-m v0.7 series.

Co-authored-by: Robert Jördens <rj@quartiq.de>
Co-authored-by: Adam Greig <adam@adamgreig.com>
@bors @TDHolmes @adamgreig
Merge #369
2f0593e 
369: Switch "native" check from being x86_64 only to checking `HOST` r=adamgreig a=TDHolmes

If `HOST==TARGET`, we know we're compiling natively. Set a new `rustc` cfg for this and use it where we previously checked for `x86_64`.

I was trying to run tests on my M1 MacBook Pro and couldn't since it isn't `x86_64`. Also, the currently configured nightly compiler for asm doesn't have M1 support, so I updated that. I'm fine reverting that change though, I can just do that locally, but I'm sure others will hit the same issue and it's a bit old...

Co-authored-by: Tyler Holmes <tyler@holmesengineering.com>
@bors @mciantyre @adamgreig
Merge #374
bbcdae6 
374: Construct a SysTick delay with a clock source r=adamgreig a=mciantyre

Helpful for users who prefer an external clock source for their system
timer. Proposing this as a 0.7 backwards-compatible change.

Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com>
@adamgreig
Prepare for v0.7.4
e3d321b
@adamgreig adamgreig requested a review from a team as a code owner December 31, 2021 17:34
@rust-highfive
Copy link

r? @thalesfragoso

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link

⚠️ Warning ⚠️

  • Pull requests are usually filed against the master branch for this repo, but this one is against v0.7.x. Please double check that you specified the right target!

@rust-highfive rust-highfive added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-cortex-m labels Dec 31, 2021
@TDHolmes
Copy link
Contributor

LGTM, but wanted to ask, the bin files are much smaller now. Did we notice that back when the inline asm changes were originally updated? I see you said:

With this change the disassembly output is identical to what we have now (phew).

so are the file size changes all just like debug info?

@adamgreig
Copy link
Member Author

Good spot, that is kind of alarming. I'll check.

@adamgreig
Copy link
Member Author

I think this is mostly a quirk of GitHub's UI - the percentage in red is the new size relative to the old size, not the size of the delta, so -1.73 KB (89%) means the new 14kB file is 1.73kB smaller than the old 16kB file, but we haven't lost 89% of the contents. Checking the archive files manually the difference does seem to be mostly in some tweaked debug info and various other apparently minor changes due to the new LLVM version. Overall doesn't look like a problem.

thejpster
thejpster approved these changes Jan 1, 2022
View reviewed changes
Copy link
Contributor

@thejpster thejpster left a comment

Choose a reason for hiding this comment

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

LGTM

@adamgreig
Copy link
Member Author

OK, let's get this out there.

bors r=thejpster

@bors
Copy link
Contributor

bors bot commented Jan 2, 2022

Build succeeded!

And happy new year! 🎉

@bors bors bot merged commit 2e2cb78 into v0.7.x Jan 2, 2022
@bors bors bot deleted the v0.7.4 branch January 2, 2022 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@thejpster thejpster thejpster approved these changes

Assignees

@thalesfragoso thalesfragoso

Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-cortex-m
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@adamgreig @rust-highfive @TDHolmes @thejpster @thalesfragoso