aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-04-16Merge #171bors[bot]
171: [NFC] fix nightly ci r=japaric a=japaric Co-authored-by: Jorge Aparicio <jorge@japaric.io>
2019-04-17now fix the fixJorge Aparicio
2019-04-16more nightly fixesJorge Aparicio
2019-04-16[NFC] fix nightly ciJorge Aparicio
2019-02-27Merge #162bors[bot]
162: v0.4.2 r=TeXitoi a=japaric this PR prepares a new release r? @korken89 || @TeXitoi Co-authored-by: Jorge Aparicio <jorge@japaric.io>
2019-02-27v0.4.2Jorge Aparicio
2019-02-26Merge #161bors[bot]
161: (ru) binds r=japaric a=japaric resubmitting PR #160 Co-authored-by: Andrey Zgarbul <zgarbul.andrey@gmail.com>
2019-02-27(ru) bindsAndrey Zgarbul
2019-02-26Merge #158bors[bot]
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>
2019-02-26refactor: make `binds` harder to misuseJorge Aparicio
2019-02-26`binds` can only appear once in the argument listJorge Aparicio
2019-02-26document the `binds` featureJorge Aparicio
cc @burrbull
2019-02-26add `binds` example and make it workJorge Aparicio
2019-02-26fix warnings in cpass testJorge Aparicio
2019-02-26make cfail test actually failJorge Aparicio
2019-02-26add some testsJorge Aparicio
2019-02-26add `binds` argument to the `interrupt` and `exception` attributesJorge Aparicio
2019-02-24Merge #159bors[bot]
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>
2019-02-23reject duplicate arguments in #[interrupt] and #[exception]Jorge Aparicio
This program was being accepted: ``` rust #[task( capacity = 1, capacity = 2, priority = 1, priority = 2, )] fn foo() {} ``` now it will trigger a compiler error
2019-02-23Merge #153bors[bot]
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>
2019-02-23fix ciJorge Aparicio
2019-02-19Merge #154bors[bot]
154: add Duration.as_cycles r=japaric a=japaric cc @oni303 Co-authored-by: Jorge Aparicio <jorge@japaric.io>
2019-02-19add Duration.as_cyclesJorge Aparicio
2019-02-19turn all potential UB into panicsJorge Aparicio
2019-02-19ci: report the size of built examplesJorge Aparicio
2019-02-19document the nightly featureJorge Aparicio
2019-02-19ci: test the nightly featureJorge Aparicio
2019-02-19add "nightly" featureJorge Aparicio
2019-02-15Merge #151bors[bot]
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>
2019-02-16rebase fixJorge Aparicio
2019-02-16cargo fmtJorge Aparicio
2019-02-16make debug builds reproducibleJorge Aparicio
2019-02-16Temporarily disable checking for reproducibility of debug builds.Hugo van der Wijst
2019-02-16Make generated names stable when sorting.Hugo van der Wijst
2019-02-16Seed RNG with package name and prepend string to full random name.Hugo van der Wijst
2019-02-16Fix thumbv6 build.Hugo van der Wijst
2019-02-16Make identifiers deterministic.Hugo van der Wijst
2019-02-16Speed up CI significantly.Hugo van der Wijst
2019-02-16Make builds reproducibleHugo van der Wijst
This is done by using `BTreeMap`s and `BTreeSet`s to get deterministic ordering. Also updated the CI job to check reproducibility of all examples.
2019-02-14fancier redirect pageJorge Aparicio
2019-02-14set a redirect from book/ to book/en/Jorge Aparicio
closes #148
2019-02-14update link to documentation in the READMEJorge Aparicio
2019-02-14update documentation link in crate metadataJorge Aparicio
2019-02-13Merge #145bors[bot]
145: fix non_camel_case_types warnings r=japaric a=japaric closes #144 Co-authored-by: Jorge Aparicio <jorge@japaric.io>
2019-02-13fix non_camel_case_types warningsJorge Aparicio
2019-02-12Merge #142bors[bot]
142: (ru) late resources r=japaric a=burrbull According to 1e9058cab2d29979da9856a8198884b50176ccbc Co-authored-by: Zgarbul Andrey <zgarbul.andrey@gmail.com>
2019-02-12bump macros versionJorge Aparicio
2019-02-12changelog: note that new syntax is documented in the bookJorge Aparicio
2019-02-12(ru) late resourcesZgarbul Andrey
According to 1e9058cab2d29979da9856a8198884b50176ccbc
2019-02-12Merge #140bors[bot]
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>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-28 04:03:17 +0000