147: Implement StableDeref for singleton::Box r=korken89 a=thalesfragoso
There was a discussion in the riot channel about what it's needed for a buffer to be DMA safe, where ra_kete came up with this POC:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=339a9a29fb59c080b42b6d77a902acb6
Where it seems that the requirements described in the [Embedonomicon](https://docs.rust-embedded.org/embedonomicon/dma.html#static-bound) doesn't seem to be enough to prevent stack corruption.
If that is really the case and we decide to use `StableDeref` instead, then a implementation for Box is very important to be able to easily use it on DMA APIs and a new point release would be necessary.
CC @korken89
Co-authored-by: thalesfragoso <thales.fragosoz@gmail.com>
142: Extend the ARMv7-A `Pool` support to the bare-metal `armv7a-` targets. r=japaric a=japaric
The built-in rustc targets ended with names that start with `armv7a-` so #140
does not cover them though the intention was to support them; this commit fixes
that
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
The built-in rustc targets ended with names that start with `armv7a-` so #140
does not cover them though the intention was to support them; this commit fixes
that
120: Allow for manual opt-out of CAS features r=japaric a=jamesmunns
I've been working on a bare metal platform lately that does not have CAS (specifically ARMv4 bare metal), and this is not caught by the CPU detection logic in the build.rs. This PR adds a flag that allows for manual specification to avoid CAS features.
Co-authored-by: James Munns <james.munns@ferrous-systems.com>
126: Add DoubleEndedIterator to queue iterators r=japaric a=david-sawatzke
The implementation is pretty straightforward and it's useful
Co-authored-by: David Sawatzke <david-sawatzke@users.noreply.github.com>
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
125: Deserialize maps as maps r=japaric a=dflemstr
The maps are already being serialized as maps, and serde_json will detect
that despite us claiming that maps are seqs, it falls back to parsing them
as maps; however, serde-json-core does not have that fallback logic, so it
makes more sense to give the correct hint here (especially when this is
merged: https://github.com/japaric/serde-json-core/pull/23)
Co-authored-by: David Flemström <david.flemstrom@gmail.com>
132: PR #121 plus regression test r=japaric a=japaric
Co-authored-by: konstantin <konstantin.kuznecov@gmx.de>
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
129: Fix improper handling of overflow in `len_usize` (fix#128) r=japaric a=david-sawatzke
This will lead to implausibly large lengths, nearly endless iterators
and possibly unsound behaviour through the Drop implementation
Switches the `truncate` method to refer to the common defintion of
simply chopping of the test bits. (Implemented by `as`, which is defined
to do this).
Adds a new `saturate` method to replace the previous `truncate` method
Co-authored-by: David Sawatzke <david-sawatzke@users.noreply.github.com>
131: remove unnecessary parentheses r=japaric a=harrysarson
This commit handles a new rustc warning currently in nightly.
I think this is why #129 failed. 🙂
Co-authored-by: Harry Sarson <harry.sarson@hotmail.co.uk>
This will lead to implausibly large lengths, nearly endless iterators
and possibly unsound behaviour through the Drop implementation
Switches the `truncate` method to refer to the common defintion of
simply chopping of the test bits. (Implemented by `as`, which is defined
to do this).
Adds a new `saturate` method to replace the previous `truncate` method
The maps are already being serialized as maps, and serde_json will detect
that despite us claiming that maps are seqs, it falls back to parsing them
as maps; however, serde-json-core does not have that fallback logic, so it
makes more sense to give the correct hint here (especially when this is
merged: https://github.com/japaric/serde-json-core/pull/23)
117: Added peek_mut for the binary heap r=japaric a=korken89
As discussed in https://github.com/japaric/heapless/issues/109, please have a look and lets bike-shed the API.
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>