304: Make the docs build r=japaric a=falk-h
Turns out there were some broken links and `#![deny(warnings)]` in the crate root.
Co-authored-by: Falk Höppner <falk@technocreatives.com>
303: Vec - PartialEq where Rhs is the Vec r=japaric a=elpiel
I was using the Vec for tests and initially, I was confused because I saw the impl for PartialEq but then I realized that PartialEq with Rhs of Vec was not implemented.
These impls are not mandatory but might help other people when using Vec on Rhs.
PS: Amazing crate btw, thanks you for the awesome work!
Co-authored-by: Lachezar Lechev <elpiel93@gmail.com>
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
302: Add clarification in String r=japaric a=mriise
Needed to look into implementation to be sure String was allocating bytes not chars.
Co-authored-by: Melanie Riise <me@mriise.net>
301: Add some more Vec methods. r=japaric a=Dirbaio
Added
- `Vec::insert(index, element)`
- `Vec::remove(index)`
- `Vec::retain(f)`
- `Vec::retain_mut(f)`
Behavior matches `std` except `insert` which is now fallible and returns back the element when full. Implementation and docs taken from `std`.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
300: Fix OOB get_unchecked, shadow Vec::as_ptr methods r=japaric a=saethlin
The fixes in #280 missed one instance of UB. The get_unchecked_mut
inside VacantEntry::Insert can be out of bounds of the initialized
region of the backing Vec. When that happens, the call is UB. This is
detected both by the standard library's debug assertions which can be
enabled with -Zbuild-std and with Miri but only with
-Zmiri-tag-raw-pointers.
This also adds inherent as_ptr and as_mut_ptr methods to Vec which
shadow those provided by the Deref to a slice. Without this shadowing,
the change from get_unchecked_mut to as_mut_ptr.add wouldn't actually
fix the problem identified by the debug assertions or Miri, it just
hides it from the debug assertions. The core problem is that references
narrow provenance, so if we want to access outside of the initialized
region of a Vec we need to get a pointer to the array without passing
through a reference to the initialized region first. The pointers from
these shadowing methods can be used to access anywhere in the allocation,
whereas vec.as_slice().as_ptr() would be UB to use for access into the
uninitialized region.
Co-authored-by: Ben Kimock <kimockb@gmail.com>
The fixes in #280 missed one instance of UB. The get_unchecked_mut
inside VacantEntry::Insert can be out of bounds of the initialized
region of the backing Vec. When that happens, the call is UB. This is
detected both by the standard library's debug assertions which can be
enabled with -Zbuild-std and with Miri but only with
-Zmiri-tag-raw-pointers.
This also adds inherent as_ptr and as_mut_ptr methods to Vec which
shadow those provided by the Deref to a slice. Without this shadowing,
the change from get_unchecked_mut to as_mut_ptr.add wouldn't actually
fix the problem identified by the debug assertions or Miri, it just
hides it from the debug assertions. The core problem is that references
narrow provenance, so if we want to access outside of the initialized
region of a Vec we need to get a pointer to the array without passing
through a reference to the initialized region first. The pointers from
these shadowing methods can be used to access anywhere in the allocation,
whereas vec.as_slice().as_ptr() would be UB to use for access into the
uninitialized region.
277: Add support for Arduino Uno and 2560 r=japaric a=mutantbob
This patch includes changes I needed to build my Arduino Uno sketches. I incorporated the work from https://github.com/japaric/heapless/pull/264 to reduce the chance of conflicts.
Now that atomic-polyfill 0.1.8 supports AVR, things are a bit easier.
Co-authored-by: Robert Forsman <git@thoth.purplefrog.com>
298: compile-time check power of two invariant in Index{Set,Map}'s default method r=korken89 a=japaric
closes#295
I tested this manually with both `FnvIndexSet` and `FnvIndexMap`. I tried to add a compile fail test but discovered (the hard way) that all the const assert trickery in `sealed` is checked when the code is built with `cargo build` but *not* when the code is built with `cargo check`. As `trybuild` uses `cargo check` under the hood it's not possible to compile fail test any of those const asserts.
r? `@korken89`
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
299: remove the scoped_threads feature gate r=japaric a=japaric
the feature has been stabilized in a recent nightly
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
262: add BinaryHeap::into_vec r=japaric a=Lambda-Logan
std::collections::BinaryHeap provides an into_vec method https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.into_vec
My use case is I want a sorted iterator similar to BinaryHeap.into_sorted_iter. I found my self creating a new heapless:Vec from heapless::BinaryHeap::into_iter and then sorting it. It seemed better to return the underlying vec and sort that.
But the functionality seemed generally useful and helps the API jive a little better with std::collections::BinaryHeap.
Do you see any issues with this implementation? Also, apologies for anything weird... This is my first PR :)
Co-authored-by: Logan Dimond <Lambda.Dimond@gmail.com>
Co-authored-by: Logan Dimond <lambda.dimond@gmail.com>
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>
