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>
151: make builds reproducible r=japaric a=japaric
This is a rebased and augmented version of #132. With this PR both dev and release builds that do not use the owned-singleton stuff become reproducible. (I haven't really bothered to make owned-singleton reproducible since [lifo] is way more ergonomic than [alloc-singleton] and will eventually make its way into heapless).
[lifo]: https://github.com/japaric/lifo
[alloc-singleton]: https://crates.io/crates/alloc-singleton
Thanks @hugwijst for doing the bulk of the work!
closes#132
Co-authored-by: Hugo van der Wijst <hvanderwijst@tesla.com>
Co-authored-by: Hugo van der Wijst <hugo@wij.st>
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
140: fix soundness issue: forbid early returns in init r=japaric a=japaric
TL;DR
1. v0.4.1 will be published once this PR lands
2. v0.4.0 will be yanked once v0.4.1 is out
3. v0.4.1 will reject code that contains early returns in `init` *and* contains
late resources. Yes, this is a breaking change but such code is unsound /
has undefined behavior.
4. as of v0.4.1 users are encouraged to use `fn init() -> init::LateResources`
instead of `fn init()` when they make use of late resources.
---
This PR fixes a soundness issue reported by @RalfJung. Basically, early
returning from `init` leaves *late resources* (runtime initialized statics)
uninitialized, and this produces undefined behavior as tasks rely on those
statics being initialized. The example below showcases a program that runs into
this soundness issue.
``` rust
#[rtfm::app(device = lm3s6965)]
const APP: () = {
// this is actually `static mut UNINITIALIZED: MaybeUninit<bool> = ..`
static mut UNINITIALIZED: bool = ();
#[init]
fn init() {
// early return
return;
// this is translated into `UNINITIALIZED.set(true)`
UNINITIALIZED = true; // the DSL forces you to write this at the end
}
#[interrupt(resources = [UNINITIALIZED])]
fn UART0() {
// `resources.UNINITIALIZED` is basically `UNINITIALIZED.get_mut()`
if resources.UNINITIALIZED {
// undefined behavior
}
}
};
```
The fix consists of two parts. The first part is producing a compiler error
whenever the `app` procedural macro finds a `return` expression in `init`. This
covers most cases, except for macros (e.g. `ret!()` expands into `return`) which
cannot be instrospected by procedural macros. This fix is technically a
breaking change (though unlikely to affect real code out there) but as per our
SemVer policy (which follows rust-lang/rust's) we are allowed to make breaking
changes to fix soundness bugs.
The second part of the fix consists of extending the `init` syntax to let the
user return the initial values of late resources in a struct. Namely, `fn() ->
init::LateResources` will become a valid signature for `init` (we allowed this
signature back in v0.3.x). Thus the problematic code shown above can be
rewritten as:
``` rust
#[rtfm::app(device = lm3s6965)]
const APP: () = {
static mut UNINITIALIZED: bool = ();
#[init]
fn init() -> init::LateResources {
// rejected by the compiler
// return; //~ ERROR expected `init::LateResources`, found `()`
// initialize late resources
init::LateResources {
UNINITIALIZED: true,
}
}
#[interrupt(resources = [UNINITIALIZED])]
fn UART0() {
if resources.UNINITIALIZED {
// OK
}
}
};
```
Attempting to early return without giving the initial values for late resources
will produce a compiler error.
~~Additionally, we'll emit warnings if the `init: fn()` signature is used to
encourage users to switch to the alternative `init: fn() -> init::LateResources`
signature.~~ Turns out we can't do this on stable. Bummer.
The book and examples have been updated to make use of `init::LateResources`.
In the next minor version release we'll reject `fn init()` if late resources
are declared. `fn init() -> init::LateResources` will become the only way to
initialize late resources.
This PR also prepares release v0.4.1. Once that version is published the unsound
version v0.4.0 will be yanked.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
