Closed adamgreig closed 4 years ago
I've pushed an update to address a couple of points that came up during reviewing #26
Outstanding nonconformances:
Debug
on our typeshtml_root_url
I'm inclined to go ahead without Debug
since it doesn't really make sense for these types. I don't know about html_root_url
and we don't seem to use it anywhere else.
Would there be any downside to deriving Debug for CriticalSection and Mutex? It seems quite possible to have a (perhaps temporary) struct containing one, and then you have to implement Debug by hand for e.g. quick debug logging purposes. Or say you have a fallible constructor that returns a critical section in a Result's error on failure, which you then can't unwrap.
I guess not, I've added that.
Last call for feedback; I'll ask again in the meeting tomorrow and if no one has any objections let's get this out there.
I don't know about
html_root_url
and we don't seem to use it anywhere else.
It is required for docs.rs links from dependencies to work correctly. We should use it in every crate (until rustdoc/docs.rs inserts it automatically).
Ah, OK. Annoying that you have to bump the version every time too. Does that look OK now?
Annoying that you have to bump the version every time too.
Yeah. This is the main reason for why I use cargo-release (and the fact that it can bump changelogs automatically too).
Build succeeded:
In 5 days it will have been exactly 3 years since v0.1.0!
I'm opening this PR so we can move discussions forward around v1; I am very happy to have some changes or more feedback before we go ahead with this.
Essentially, this crate is now just
CriticalSection
andMutex
, which are widely used and probably won't change without becoming something totally new (e.g. the new mutex-trait crate). There are some known issues (especially CSs don't disable NMI or HardFault) which perhaps could be documented and understood better, but I think are all platform-specific (cortex-m).In this PR:
StaticResource
: it's not been released in any published version so hasn't been proven yet; we could re-add it in a later release or separate cratedeny(warnings)
and instead deny them in CIWe'll still want to close off #26. Otherwise I think everything from #22 is covered.