293: unconditionally depend on atomic-polyfill for riscv32i target r=japaric a=japaric
due to a limitation in the llvm backend [1] the `riscv32i-unknown-none-elf` target lacks the `core::sync::atomic` API even though the actual hardware is capable of atomic loads and stores (`fence` instruction). thus, at this point in time, this target needs `atomic-polyfill` for a working SPSC implementation
[1]: https://github.com/knurling-rs/defmt/issues/597#issuecomment-934467023fixes#271closes#272closes#273
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
264: Add support for AVR. r=japaric a=jeremysalwen
In order to support AVR, the following changes were made:
- AVR was added to the list of architectures not supporting atomics or cas.
- AVR was configured to not use AtomicUsize, similarly to armv6m.
- SortedLinkedList was modified to account for the fact that usize is differently sized on
different architectures (16 bits on AVR).
Co-authored-by: Jeremy Salwen <jeremysalwen@gmail.com>
289: entry API for IndexMap r=japaric a=japaric
rebased version of PR #276
`@MarcusGrass` thanks for the PR!
Co-authored-by: gramar <marcus.grass@gmail.com>
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
274: Implement FromIterator for String r=japaric a=VersBinarii
Implements FromIterator trait on String.
It also addresses issue: https://github.com/japaric/heapless/issues/245
Co-authored-by: VersBinarii <versbinarii@gmail.com>
280: Fix undefined behavior identified by Miri r=japaric a=jgallagher
Hi! We ran into an exception triggered by new undefined behavior checks inserted into the nightly compiler (https://github.com/rust-lang/rust/pull/92686/files#diff-54110dcedc5a4d976321aa5d2a6767ac0744a3ef1363b75ffc62faf81cf14c30R230-L229). Running `heapless`'s test suite under Miri didn't flag anything at first, but it did once we added `MIRIFLAGS="-Zmiri-tag-raw-pointers"`. All three of the fixes in this PR were identified via
```
MIRIFLAGS="-Zmiri-tag-raw-pointers -Zmiri-ignore-leaks" cargo +nightly miri test -- --skip pool::
```
and the fixes came from copying the implementations from the equivalent methods in `std`. Note that I skipped the `pool::` tests; there is at least one miri failure in them, but it wasn't immediately obvious how to fix it so I skipped it for now. It's probably worth adding the flag above to the CI miri run, but I didn't do that either (since it would immediately cause failures given I didn't fix the problem in `pool`).
The specific output for `pool` is
```
test pool::singleton::tests::sanity ... error: Undefined Behavior: trying to reborrow <untagged> for SharedReadWrite permission at alloc36[0x1], but that tag does not exist in the borrow stack for this location
--> /home/john/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:380:18
|
380 | unsafe { &*self.as_ptr() }
| ^^^^^^^^^^^^^^^
| |
| trying to reborrow <untagged> for SharedReadWrite permission at alloc36[0x1], but that tag does not exist in the borrow stack for this location
| this error occurs as part of a reborrow at alloc36[0x1..0x9]
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
= note: inside `std::ptr::NonNull::<pool::stack::Node<u8>>::as_ref` at /home/john/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/non_null.rs:380:18
note: inside `pool::stack::Stack::<u8>::push` at src/pool/cas.rs:43:17
--> src/pool/cas.rs:43:17
|
43 | / new_head
44 | | .as_raw()
45 | | .as_ref()
| |_____________________________^
note: inside `pool::Pool::<u8>::grow` at src/pool/mod.rs:390:25
--> src/pool/mod.rs:390:25
|
390 | self.stack.push(p);
| ^^^^^^^^^^^^^^^^^^
note: inside `<pool::singleton::tests::sanity::A as pool::singleton::Pool>::grow` at src/pool/singleton.rs:78:9
--> src/pool/singleton.rs:78:9
|
78 | Self::ptr().grow(memory)
| ^^^^^^^^^^^^^^^^^^^^^^^^
note: inside `pool::singleton::tests::sanity` at src/pool/singleton.rs:362:9
--> src/pool/singleton.rs:362:9
|
362 | A::grow(unsafe { &mut MEMORY });
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: inside closure at src/pool/singleton.rs:353:5
--> src/pool/singleton.rs:353:5
|
352 | #[test]
| ------- in this procedural macro expansion
353 | / fn sanity() {
354 | | const SZ: usize = 2 * mem::size_of::<Node<u8>>() - 1;
355 | | static mut MEMORY: [u8; SZ] = [0; SZ];
356 | |
... |
373 | | assert_eq!(*A::alloc().unwrap().init(1), 1);
374 | | }
| |_____^
= note: this error originates in the attribute macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Co-authored-by: John Gallagher <john@oxidecomputer.com>
as it's easier to deal with TSAN false positives in the former API
as surfaced in PR 280 the current supression rules don't handle newer versions of the
scoped_threadpool crate
trying to update the supression rules related to scoped_threadpool in PR #282 revealed that the
supression rules are masking (hiding) real data races:
https://github.com/japaric/heapless/pull/282#issuecomment-1113173358
std:🧵:scope requires less supression rules and does not mask real data races -- for instance,
the data race in the linked issue comment is not masked when using std:🧵:scope
tradeoffs:
- pro: one less dev dependency
- pro: supressions file is simpler
- cons: std:🧵:scope is only available on recent nightlies
In order to support AVR, the following changes were made:
- AVR was added to the list of architectures supported by atomic-polyfill.
- SortedLinkedList was modified to account for the fact that usize is
differently sized on different architectures (16 bits on AVR).
