635: Masks take 3 r=AfoHT a=korken89
This solves the `MASKS` generation issue by having `rtic::export` do the feature gating.
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
589: Fine grained concurrency on thumbv6m (no BASEPRI). r=korken89 a=perlindgren
This is an experimental implementation of SRP based scheduling on the M0/M0+ (thumbv6m) architecture.
The aim is a (sub)-zero abstraction to the resource protection (locking mechanism).
Please try, but not merge yet, since its an early POC.
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
616: rtic::mutex::prelude::* fixes glob import lint r=korken89 a=AfoHT
Running cargo Clippy with pedantic rules denied
```
cargo clippy -- --deny clippy::pedantic
```
it will complain:
```
error: usage of wildcard import
|
16 | use rtic::mutex_prelude::*;
| ^^^^^^^^^^^^^^^^^^^^^^ help: try: `rtic::mutex_prelude::{Mutex, TupleExt01, TupleExt02, TupleExt03, TupleExt04, TupleExt05, TupleExt06, TupleExt07, TupleExt08, TupleExt09, TupleExt10, TupleExt11, TupleExt12, TupleExt13, TupleExt14, TupleExt15, TupleExt16, TupleExt17, TupleExt18, TupleExt19, TupleExt20, TupleExt21, TupleExt22, TupleExt23, TupleExt24, TupleExt25, TupleExt26, TupleExt27, TupleExt28, TupleExt29, TupleExt30, TupleExt31, TupleExt32}`
|
= note: `-D clippy::wildcard-imports` implied by `-D clippy::pedantic`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#wildcard_imports
error: could not compile --- due to previous error
Error: command `cargo clippy -- --deny clippy::all --deny clippy::pedantic` failed, exit status: 101
```
Looking at the Clippy [wildcard-imports rule](https://rust-lang.github.io/rust-clippy/master/#wildcard_imports)
the exception is for wildcards on modules named prelude. Thus, `prelude::*` is OK.
Current state: `use rtic-core::prelude as mutex_prelude` almost fits the bill, but `mutex_prelude != prelude`.
As this was part of user facing API I don’t think we can remove the current setup,
so rtic-core `Mutex`, `Exclusive` and multi-lock `TupleExt0X` retained in
old location to be backwards compatible.
Co-authored-by: Henrik Tjäder <henrik@grepit.se>
610: GHA: Print current crate version too r=perlindgren a=AfoHT
613: Docs: fix link r=perlindgren a=AfoHT
Co-authored-by: Henrik Tjäder <henrik@grepit.se>
606: GHA: Automatic merge to release/vX r=perlindgren a=AfoHT
- Require clippy for deploy
- GHA: Automatic merge to release/vX
- Link dev-book to stable if they are describe the same release
- Update CHANGELOG
Development work is done in the master branch
Older versions previously were found in v0.5.x, v0.4.x branches.
Now with v1 released, and any breaking change forcing a v2,
a need to streamline documentation building arose.
The different docs:
- rtic.rs
- latest stable (v1)
- API documentation
- RTIC book
- old stable (v0.5)
- API documentation
- RTIC book
- oldold stable (v0.4)
- API documentation
- RTIC book
- docs.rs
- all previous crates.io releases
- API documentation
With this PR, when a pull request gets merged to master
with CI passing the current master branch gets merged
to `release/v$VERSION` where `$VERSION` is parsed from
cargo metadata of cortex-m-rtic.
The deployment of docs GHA job is dependent on this merge job,
and therefore the docs published to rtic.rs will contain the latest
content from the merged PR.
Assuming the current situation where `v1` is the latest stable,
a PR should trigger a merge to `release/v1` and then docs gets pushed
to `gh-pages` branch (rtic.rs).
For the future, when the latest stable is still `v1`, but the current
dev version in `master` branch is `v2` the GHA job will push to `release/v2` (dev branch).
For the future we might decide if this push of the dev branch is desirable.
If the current stable version and dev version share the same major version,
the dev book redirection on rtic.rs will point to the stable book instead.
Co-authored-by: Henrik Tjäder <henrik@grepit.se>
605: GHA: Tune CI r=AfoHT a=AfoHT
- GHA: Use rust-cache
- GHA: Cleanup single target jobs
- GHA: Add cargo clippy
Co-authored-by: Henrik Tjäder <henrik@grepit.se>
