338: export all IndexMap iterators r=korken89 a=jeandudey
Exports all the iterator types of `IndexMap`.
I wonder if it'd make sense to have a module structure such as the one in `alloc::collections`, e.g.: `heapless::indexmap` and re-export `heapless::indexmap::IndexMap` on the crate root, to have all the iterator types inside the `indexmap` module but still public.
Co-authored-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
337: Update spin dependency to newer version r=korken89 a=the-real-adammork
This updates `spin` to the newest version, this change helps us in one of our repos.
Co-authored-by: Adam Mork <adam@mobilecoin.com>
326: Recover StableDeref trait for pool::object::Object and pool::boxed::Box r=korken89 a=qwerty19106
I add ReadBuffer and WriteBuffer to pool::object::Object and pool::box::Box.
It allows to use embedded DMA of HAL crates, such as [stm32f4xx_hal::dma::Transfer](https://docs.rs/stm32f4xx-hal/latest/stm32f4xx_hal/dma/struct.Transfer.html).
Co-authored-by: Роман Кривенков <qwerty19106@gmail.com>
327: Add HistoryBuffer::as_slices() r=korken89 a=hulthe
This method returns the contents of a HistoryBuffer as two ordered slices, similar to [Deque::as_slices()](https://docs.rs/heapless/0.7.16/heapless/struct.Deque.html#method.as_slices).
Co-authored-by: Joakim Hulthe <joakim@hulthe.net>
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
335: Implement retain for IndexSet/IndexMap. r=korken89 a=jeandudey
Needed to remove IndexMap/IndexSet elements while iterating over it.
Co-authored-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
332: Export Iter from IndexSet and IndexMap r=korken89 a=jeandudey
Exports the `Iter` types for `IndexSet` and `IndexMap`.
My use case is having a trait generic over a `BTreeSet` and `IndexSet` which has a `type Iter`.
Co-authored-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
331: Relax trait requirements on IndexMap/IndexSet. r=korken89 a=jeandudey
Some requirements are not necessary and the specification can be removed/simplified. This makes these types a bit more ergonomic when using them in a trait or function definition as not all traits need to be specified for some cases.
Co-authored-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
320: switch to a more recent atomic-polyfill that compiles for AVR r=japaric a=japaric
cleaned up version of PR #313closes#313
Co-authored-by: Robert Forsman <git@thoth.purplefrog.com>
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
316: speed up cargo miri test r=japaric a=japaric
by making some "exhaustive" tests less exhaustive
317: impl {Clone, PartialEq} for HistoryBuffer {...} r=japaric a=finnbear
- `impl Clone for HistoryBuffer`
- `impl PartialEq for HistoryBuffer`
Both are tested fairly rigorously.
Motivation is to use this type in a `yew::Properties` struct, which requires both traits to be implemented.
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
Co-authored-by: Finn Bear <finnbearlabs@gmail.com>
319: update compile_fail test to work on 1.64 r=japaric a=japaric
should fix CI and unblock PRs like #317
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
284: [breaking-change] use hash32 v0.3.0 r=japaric a=japaric
this release of `hash32` has the advantage that 32-bit hashers can be used to hash types that
implement the `core:#️⃣:Hash` trait removing the need for the `hash32::Hash` implementations in
this crate and the uses of the `#[derive(Hash32)]` macro (which did not support enums) in dependent
crates
with this change the following code works
``` rust
// NOTE no derive(Hash32)
#[derive(Hash)]
struct Int(i32);
let mut x = FnvIndexSet::<_, 4>::default();
let _ = x.insert(Int(0));
```
this change is technically a breaking change because the following code is no longer accepted
``` rust
// assume this type comes from a dependency
// NOTE no derive(Hash)
#[derive(Hash32)]
struct Int(i32);
let mut x = FnvIndexSet::<_, 4>::default();
let _ = x.insert(Int(0)); // error: does not implement Hash
```
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
311: ci: run miri tests first r=japaric a=japaric
it seems runners are assigned to jobs in the order they appear in the
yaml file. miri takes the longest so it's better if it appears first
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
