Remove raw_pointer_deriving lint

[devonhollowood]

Implement #14615

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (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. 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.

[Manishearth]

@bors r+

Looks good to me, thanks!

[bors]

📌 Commit 5e8225a has been approved by Manishearth

[bors]

⌛ Testing commit 5e8225a with merge 71bcaa1...

[bors]

💔 Test failed - auto-mac-64-opt

[Manishearth]

../src/liblibc/src/lib.rs:13:21: 13:39 error: unknown `allow` attribute: `raw_pointer_derive`, #[deny(unknown_lints)] on by default
../src/liblibc/src/lib.rs:13 #![allow(bad_style, raw_pointer_derive, overflowing_literals, improper_ctypes)]
                                                 ^~~~~~~~~~~~~~~~~~
error: aborting due to previous error

You'll have to open a PR to https://github.com/rust-lang-nursery/libc first to remove that, and then update the submodule. Sorry about that. Let me know if you need help (or want me to do it for you) 😄

[Manishearth]

@alexcrichton Do we consider breakages in allow lints (e.g. unknown_lints in this case) to be a breaking change? Especially since cargo does that lint cap thing.

[devonhollowood]

I submitted a pull request to libc.
If we do consider this a breaking change, maybe it makes more sense to go back and change the default lint level from Warn to Allow instead of the changes here (which to my understanding would be non-breaking). If we do decide to do that, would it be cleaner to do so from a new pull request?

[alexcrichton]

Nah this isn't a breaking change because it's just tweaking lints, which aren't considered breaking changes (due to --cap-lints)

[Manishearth]

Cool.

@devonhollowood It landed, so you need to now update the submodule to rust-lang/libc@8531cc1 and add it to your commit. If you need help:

cd src/liblibc
git fetch origin
git checkout 8531cc11e196b7ae9072ae7b384a930ff7b00dfb
cd ..
git add liblibc
git commit --amend

or something like that.

[Manishearth]

@bors r+

[bors]

📌 Commit 0823ee6 has been approved by Manishearth

[bors]

⌛ Testing commit 0823ee6 with merge 50b969d...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[brson]

This caused breakage. I was under the impression that lints are never supposed to be removed because of this problem and simply turned to no-ops.

[Manishearth]

I thought lint changes are fine because of lint capping?