191: generate resource proxies only when needed r=japaric a=japaric
only `static mut` resources need proxies
just a codegen optimization
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
175: document internals r=japaric a=japaric
note that this assumes that RFC #155 has been implemented
[Rendered text](https://japaric.github.io/rtfm5/book/en/internals.html)
Do not merge this before PR #176
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
176: implement RFCs 147 and 155, fix#141, etc. r=japaric a=japaric
This PR:
- Implements RFC 147: "all functions must be safe"
- Implements RFC 155: "explicit Context parameter"
- Implements the pending breaking change #141: reject assign syntax in `init`
(which was used to initialize late resources)
- Refactors code generation to make it more readable -- there are no more random
identifiers in the output -- and align it with the book description of RTFM
internals (see PR #175).
- Makes the framework hard depend on `core::mem::MaybeUninit` and thus will
require nightly until that API is stabilized.
- Fixes a ceiling analysis bug where the priority of the system timer was not
considered in the analysis (TODO backport this into the v0.4.x branch).
- Shrinks the size of all the internal queues by turning `AtomicUsize` indices
into `AtomicU8`s.
- Removes the integration with `owned_singleton`.
closes#141closes#147closes#155
Additionally:
- This changes CI to push v0.5.x docs to
https://japaric.github.io/rtfm5/book/en/ -- we need to do this because our
official docs are hosted on https://japaric.github.io/cortex-m-rtfm and we
need to keep them on v0.4.x until we release v0.5.0
- I propose that we use the master branch to develop the upcoming v0.5.0.
- I have created a branch v0.4.x for backports; new v0.4.x releases will come
from that branch.
r? @korken89 @texitoi, sorry for doing all the impl work in a single commit --
I know that makes things harder to review for you.
Suggestions for compile-pass and compile-fail tests are welcome
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
This commit:
- Implements RFC 147: "all functions must be safe"
- Implements RFC 155: "explicit Context parameter"
- Implements the pending breaking change #141: reject assign syntax in `init`
(which was used to initialize late resources)
- Refactors code generation to make it more readable -- there are no more random
identifiers in the output -- and align it with the book description of RTFM
internals.
- Makes the framework hard depend on `core::mem::MaybeUninit` and thus will
require nightly until that API is stabilized.
- Fixes a ceiling analysis bug where the priority of the system timer was not
considered in the analysis.
- Shrinks the size of all the internal queues by turning `AtomicUsize` indices
into `AtomicU8`s.
- Removes the integration with `owned_singleton`.
170: check task priority at compile time r=TeXitoi a=japaric
before we were checking the priority at runtime. The compile time error message
when the priority is too high is kind of awful though.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
158: implement RFC #128: #[interrupt(binds = ..)] r=korken89 a=japaric
closes#128
r? @korken89 or @TeXitoi
suggestions for tests are welcome! (2 of the 3 tests I added hit bugs in my implementation)
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
159: reject duplicate arguments in #[interrupt] and #[exception] r=TeXitoi a=japaric
This program was being accepted:
``` rust
#[task(
capacity = 1,
capacity = 2,
priority = 1,
priority = 2,
)]
fn foo() {}
```
now it will trigger a compiler error
r? @korken89 || @TeXitoi
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
This program was being accepted:
``` rust
#[task(
capacity = 1,
capacity = 2,
priority = 1,
priority = 2,
)]
fn foo() {}
```
now it will trigger a compiler error
153: add "nightly" feature; replace hint::unreachable_unchecked with a panic r=korken89 a=japaric
this implements the action plan described in #149
to give you a sense of the overhead of this change: it has increased the binary
size of some of our examples by up to 10% but this is mainly from pulling in a
panic handler that does formatting
r? @korken89
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
