Removed changes from lib.rs file and synced upstream master

Author: justacec

.github/bors.toml

@@ -1,4 +1,9 @@
 block_labels = ["needs-decision"]
 delete_merged_branches = true
 required_approvals = 1
-status = ["continuous-integration/travis-ci/push"]
+status = [
+  "ci-linux (stable, x86_64-unknown-linux-gnu)",
+  "ci-linux (stable, thumbv6m-none-eabi)",
+  "ci-linux (stable, thumbv7m-none-eabi)",
+  "ci-linux (1.35.0, x86_64-unknown-linux-gnu)",
+]

.github/workflows/ci.yml

@@ -0,0 +1,40 @@
+on:
+  push:
+    branches: [ staging, trying, master ]
+  pull_request:
+
+name: Continuous integration
+
+jobs:
+  ci-linux:
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        # All generated code should be running on stable now
+        rust: [stable]
+
+        # The default target we're compiling on and for
+        TARGET: [x86_64-unknown-linux-gnu, thumbv6m-none-eabi, thumbv7m-none-eabi]
+
+        include:
+          # Test MSRV
+          - rust: 1.35.0
+            TARGET: x86_64-unknown-linux-gnu
+
+          # Test nightly but don't fail
+          - rust: nightly
+            experimental: true
+            TARGET: x86_64-unknown-linux-gnu
+
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions-rs/toolchain@v1
+        with:
+          profile: minimal
+          toolchain: ${{ matrix.rust }}
+          target: ${{ matrix.TARGET }}
+          override: true
+      - uses: actions-rs/cargo@v1
+        with:
+          command: check
+          args: --target=${{ matrix.TARGET }}

.github/workflows/clippy.yml

@@ -0,0 +1,20 @@
+on:
+  push:
+    branches: [ staging, trying, master ]
+  pull_request:
+
+name: Clippy check
+jobs:
+  clippy_check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions-rs/toolchain@v1
+        with:
+          profile: minimal
+          toolchain: stable
+          override: true
+          components: clippy
+      - uses: actions-rs/clippy-check@v1
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/rustfmt.yml

@@ -0,0 +1,23 @@
+on:
+  push:
+    branches: [ staging, trying, master ]
+  pull_request:
+
+name: Code formatting check
+
+jobs:
+  fmt:
+    name: Rustfmt
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions-rs/toolchain@v1
+        with:
+          profile: minimal
+          toolchain: stable
+          override: true
+          components: rustfmt
+      - uses: actions-rs/cargo@v1
+        with:
+          command: fmt
+          args: --all -- --check

.travis.yml

@@ -5,14 +5,27 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/)
 and this project adheres to [Semantic Versioning](http://semver.org/).
 
+
 ## [Unreleased]
 
+## [v1.0.0-alpha.1] - 2020-06-16
+
+*** This is an alpha release with breaking changes (sorry) ***
+
 ### Added
 - A nonblocking trait for interfacing with random number generation hardware.
 
 ### Changed
-- The current versions of `InputPin` have been proven. These are `digital::v1::InputPin` 
-  and `digital::v2::InputPin`.
+- All traits have been marked as proven (`unproven` feature has been removed).
+- All trait methods have been made fallible.
+- All trait methods have been renamed `try_*` (i.e. `try_send`) for consistency.
+- The `Capture`, `Pwm`, `PwmPin` and `Qei` traits have been moved into their own
+  `capture`, `pwm` and `qei` modules for consistency.
+- Void has been replaced with `core::convert::Infallible` which should be used
+  in trait implementations where methods cannot fail.
+- A new [process](https://github.com/rust-embedded/embedded-hal#how-to-add-a-new-trait)
+  has been adopted for the addition of traits to the embedded-hal. 
+- The minimum supported Rust version is 1.35 due to [this issue](https://github.com/rust-lang/rust/issues/54973).
 
 ## [v0.2.3] - 2019-05-09
 
@@ -99,8 +112,11 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 
 Initial release
 
-[Unreleased]: https://github.com/japaric/embedded-hal/compare/v0.2.1...HEAD
-[v0.2.1]: https://github.com/japaric/embedded-hal/compare/v0.2.0...v0.2.1
-[v0.2.0]: https://github.com/japaric/embedded-hal/compare/v0.1.2...v0.2.0
-[v0.1.2]: https://github.com/japaric/embedded-hal/compare/v0.1.1...v0.1.2
-[v0.1.1]: https://github.com/japaric/embedded-hal/compare/v0.1.0...v0.1.1
+[Unreleased]: https://github.com/rust-embedded/embedded-hal/compare/v1.0.0-alpha.1...HEAD
+[v1.0.0-alpha.1]: https://github.com/rust-embedded/embedded-hal/compare/v0.2.3...v1.0.0-alpha.1
+[v0.2.3]: https://github.com/rust-embedded/embedded-hal/compare/v0.2.2...v0.2.3
+[v0.2.2]: https://github.com/rust-embedded/embedded-hal/compare/v0.2.1...v0.2.2
+[v0.2.1]: https://github.com/rust-embedded/embedded-hal/compare/v0.2.0...v0.2.1
+[v0.2.0]: https://github.com/rust-embedded/embedded-hal/compare/v0.1.2...v0.2.0
+[v0.1.2]: https://github.com/rust-embedded/embedded-hal/compare/v0.1.1...v0.1.2
+[v0.1.1]: https://github.com/rust-embedded/embedded-hal/compare/v0.1.0...v0.1.1

CHANGELOG.md

@@ -12,17 +12,12 @@ license = "MIT OR Apache-2.0"
 name = "embedded-hal"
 readme = "README.md"
 repository = "https://github.com/rust-embedded/embedded-hal"
-version = "0.2.3"
+version = "1.0.0-alpha.1"
 
-[dependencies.nb]
-version = "0.1.1"
+[dependencies]
+nb = { version = "0.1.1", features = ["unstable"] }
 
 [dev-dependencies]
 stm32f3 = { version = "0.8", features = ["stm32f303", "rt"] }
 futures = "0.1.17"
 
-[features]
-unproven = ["nb/unstable"]
-
-[package.metadata.docs.rs]
-features = ["unproven"]

Cargo.toml

@@ -12,46 +12,29 @@ This project is developed and maintained by the [HAL team][team].
 
 This is the suggested approach to adding a new trait to `embedded-hal`
 
-### Discussion
+### Research / Discussion
 
-Ideally, before proposing a new trait, or set of traits, you should create an issue where the use
-cases and requirements of the trait(s) are discussed.
+Ideally, before proposing a new trait, or set of traits, you should check for an existing issue
+suggesting the need for the trait, as well as any related works / use cases / requirements that
+are useful to consider in the design of the trait.
 
-These issues will be labeled as `discussion`s in the issue tracker.
+These issues will be labeled as `discussion` in the issue tracker.
 
-### Proposing a trait
-
-Once there's consensus on the requirements of the trait(s) a new issue, or a PR, with a proposal
-should be opened. The proposal should include the actual trait definitions as well as a link to the
-issue with previous discussion, if there was one.
+### Implementation / Demonstration
 
-If the proposal includes more than one alternative then there should be further discussion to try to
-single out the best alternative.
+Proposed traits should then be implemented and demonstrated, either by forking `embedded-hal` or by creating a new crate with the intent of integrating this into `embedded-hal` once the traits have stabilized. You may find [cargo workspaces](https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html) and [patch](https://doc.rust-lang.org/edition-guide/rust-2018/cargo-and-crates-io/replacing-dependencies-with-patch.html) useful for the forking approach.
 
-These issues / PRs will be labeled as `proposal`s in the issue tracker.
+Traits should be demonstrated with at least *two* implementations on different platforms and *one* generic driver built on the trait. Where it is possible we suggest an implementation on a microcontroller, and implementation for [linux](https://github.com/rust-embedded/linux-embedded-hal), and a driver (or drivers where requirements are more complex) with bounds using the trait.
 
-### Testing period
+### Proposing a trait
 
-If there are no objections to the proposal the new trait(s) will land behind the "unproven" Cargo
-feature and an issue about the new trait(s) will be created. If the proposal includes several
-alternatives and a single one couldn't be chosen as the best then each alternative will land behind
-a different Cargo feature, e.g. "alt1" or "alt2".
+Once the trait has been demonstrated a PR should be opened to merge the new trait(s) into `embedded-hal`. This should include a link to the previous discussion issue.
 
-The traits will undergo a testing period before they move into the set of proven traits. During
-this period users are encouraged to try to implement the unproven traits for their platforms and to
-build drivers on top of them. Problems implementing the trait(s) as well as successful
-implementations should be reported on the corresponding issue.
+If there is determined to be more than one alternative then there should be further discussion to 
+try to single out the best option. Once there is consensus this will be merged into the `embedded-hal` repository.
 
-To leave the unproven state at least *two* implementations of the trait(s) for different platforms
-(ideally, the two platforms should be from different vendors) and *one* generic driver built on top
-of the trait(s), or alternatively one demo program that exercises the trait (via generic function /
-trait object), *should* be demonstrated. If, instead, reports indicate that the proposed trait(s)
-can't be implemented for a certain platform then the trait(s) will be removed and we'll go back to
-the drawing board.
+These issues / PRs will be labeled as `proposal`s in the issue tracker.
 
-Issues used to track unproven APIs will be labeled as `unproven-api`s in the issue tracker and they
-may also include the labels `needs-impl` and `needs-driver` to signal what's required for them to
-move to the set of proven traits.
 
 ## Implementations and drivers
 
@@ -60,6 +43,11 @@ list.
 
 [awesome-embedded-rust]: https://github.com/rust-embedded/awesome-embedded-rust#driver-crates
 
+# Minimum Supported Rust Version (MSRV)
+
+This crate is guaranteed to compile on stable Rust 1.35 and up. It *might*
+compile with older versions but that may change in any new patch release.
+
 ## License
 
 Licensed under either of