Remove #[deny(warnings)]

[dbrgn]

The library currently does not currently build anymore, because upstream libraries have added new deprecation warnings. A deprecation warning should not break compilation though. There was a post on Reddit about this about a year ago, but I can't find it anymore.

I think adding a CI check step would be fine, but #[deny(warnings)] is a bit too much.

These are the warnings:

warning: use of deprecated item 'hal::digital::OutputPin': Deprecated because the methods cannot return errors. Users should use the traits in digital::v2.
   --> src/lib.rs:111:6                                                       
    |                                                                         
111 | impl hal::digital::OutputPin for Pin {                                  
    |      ^^^^^^^^^^^^^^^^^^^^^^^                                            
    |                                                                         
    = note: #[warn(deprecated)] on by default                                 

warning: use of deprecated item 'hal::digital::InputPin': Deprecated because the methods cannot return errors. Users should use the traits in digital::v2.
   --> src/lib.rs:121:6                                                       
    |                                                                         
121 | impl hal::digital::InputPin for Pin {                                   
    |      ^^^^^^^^^^^^^^^^^^^^^^                                             

warning: use of deprecated item 'hal::digital::InputPin::is_high': Deprecated because the methods cannot return errors. Users should use the traits in digital::v2.
   --> src/lib.rs:131:15                                                      
    |                                                                         
131 |         !self.is_high()                                                 
    |               ^^^^^^^                                                                                                                             

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nastevens (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[therealprof]

That's actually an anti-pattern: https://github.com/rust-unofficial/patterns/blob/master/anti_patterns/deny-warnings.md

[hannobraun]

bors r=therealprof

[bors[bot]]

:lock: Permission denied

Existing reviewers: click here to make hannobraun a reviewer

[hannobraun]

Permission denied

Ah, looks like the decision to remove the HAL team as a maintainer has already been implemented. Sorry for the noise.

[posborne]

bors r=therealprof

[bors[bot]]

Build failed

• continuous-integration/travis-ci/push

[dbrgn]

The bors failure seems unrelated. What can we do to get this merged?

[therealprof]

I think it is me messing up the process because I'm not really a authorised reviewer on this repository. ;) If @posborne would just do bors r+, that might end up fine. ;)

[posborne]

bors r+

[bors[bot]]

Build failed

• continuous-integration/travis-ci/push

[therealprof]

Hm, okay, another problem with nightly... libc messed up:

error[E0425]: cannot find value `PTRACE_GETFPXREGS` in module `libc`
  --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/nix-0.11.0/src/sys/ptrace.rs:77:9
   |
77 |         PTRACE_GETFPXREGS,
   |         ^^^^^^^^^^^^^^^^^
help: a constant with a similar name exists
   |
77 |         PTRACE_GETFPREGS,
   |         ^^^^^^^^^^^^^^^^
help: possible candidate is found in another module, you can import it into scope
   |
3  | use sys::ptrace::Request::PTRACE_GETFPXREGS;

[rnestler]

Hm, okay, another problem with nightly... libc messed up:

Why test this with nightly anyways? It compiles fine on stable.

[ryankurte]

@therealprof i ran into this today, tested to be resolved in https://github.com/nix-rust/nix/pull/1055, i've asked them to publish a release https://github.com/nix-rust/nix/pull/1061 which i guess will have to be individually bumped in sysfs_gpio, i2cdev and spidev and then updated here.

[ryankurte]

@rnestler it appears broken to me on both stable and nightly when cross compiling for arm. maybe we should add stable to the build matrix too?

[therealprof]

bors r+

[bors[bot]]

Build succeeded

• continuous-integration/travis-ci/push

[dbrgn]

:tada: