-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend the #[must_use]
lint to arrays
#62235
Conversation
r=me with CI passing, the first nit fixed, and optionally the second. @rust-lang/lang N.B. This PR extends |
ffc5bf7
to
0fccbf0
Compare
@bors r=Centril |
📌 Commit 0fccbf0 has been approved by |
…entril Extend the `#[must_use]` lint to arrays Based on top of rust-lang#62228. r? @Centril
@bors r- ; seems we have a toolstate failure in #62242 (comment). |
This will be fixed once rust-lang/miri#806 is merged. |
r=me then :) |
@bors r=Centril |
📌 Commit 0fccbf0 has been approved by |
0fccbf0
to
76f5b50
Compare
@bors r=Centril |
📌 Commit 76f5b50 has been approved by |
…entril Extend the `#[must_use]` lint to arrays Based on top of rust-lang#62228. r? @Centril
Rollup of 8 pull requests Successful merges: - #62062 (Use a more efficient iteration order for forward dataflow) - #62063 (Use a more efficient iteration order for backward dataflow) - #62224 (rustdoc: remove unused derives and variants) - #62228 (Extend the #[must_use] lint to boxed types) - #62235 (Extend the `#[must_use]` lint to arrays) - #62239 (Fix a typo) - #62241 (Always parse 'async unsafe fn' + properly ban in 2015) - #62248 (before_exec actually will only get deprecated with 1.37) Failed merges: r? @ghost
Extend `#[must_use]` to nested structures Extends the `#[must_use]` lint to apply when `#[must_use]` types are nested within `struct`s (or one-variant `enum`s), making the lint much more generally useful. This is in line with #61100 extending the lint to tuples. Fixes #39524. cc @rust-lang/lang and @rust-lang/compiler for discussion in case this is a controversial change. In particular, we might want to consider allowing annotations on fields containing `#[must_use]` types in user-defined types (e.g. `#[allow(unused_must_use)]`) to opt out of this behaviour, if there are cases where we this this is likely to have frequent false positives. (This is based on top of #62235.)
Extend `#[must_use]` to nested structures Extends the `#[must_use]` lint to apply when `#[must_use]` types are nested within `struct`s (or one-variant `enum`s), making the lint much more generally useful. This is in line with #61100 extending the lint to tuples. Fixes #39524. cc @rust-lang/lang and @rust-lang/compiler for discussion in case this is a controversial change. In particular, we might want to consider allowing annotations on fields containing `#[must_use]` types in user-defined types (e.g. `#[allow(unused_must_use)]`) to opt out of this behaviour, if there are cases where we this this is likely to have frequent false positives. (This is based on top of #62235.)
Extend `#[must_use]` to nested structures Extends the `#[must_use]` lint to apply when `#[must_use]` types are nested within `struct`s (or one-variant `enum`s), making the lint much more generally useful. This is in line with #61100 extending the lint to tuples. Fixes #39524. cc @rust-lang/lang and @rust-lang/compiler for discussion in case this is a controversial change. In particular, we might want to consider allowing annotations on fields containing `#[must_use]` types in user-defined types (e.g. `#[allow(unused_must_use)]`) to opt out of this behaviour, if there are cases where we this this is likely to have frequent false positives. (This is based on top of #62235.)
Pkgsrc changes: * Add a patch to llvm to deal with const dli_saddr. * Adapt two other patches. * Cross-build currently fails, so i386, powerpc and sparc64 bootstrap kits for 1.37.0 are built natively. Missing aarch64 hardware, so that's not available yet. * Bump bootstrap requirements to 1.36.0 except for armv7-unknown-netbsd-eabihf which I've not managed to cross-build. Upstream changes: Version 1.37.0 (2019-08-15) ========================== Language -------- - `#[must_use]` will now warn if the type is contained in a [tuple][61100], [`Box`][62228], or an [array][62235] and unused. - [You can now use the `cfg` and `cfg_attr` attributes on generic parameters.][61547] - [You can now use enum variants through type alias.][61682] e.g. You can write the following: ```rust type MyOption = Option<u8>; fn increment_or_zero(x: MyOption) -> u8 { match x { MyOption::Some(y) => y + 1, MyOption::None => 0, } } ``` - [You can now use `_` as an identifier for consts.][61347] e.g. You can write `const _: u32 = 5;`. - [You can now use `#[repr(align(X)]` on enums.][61229] - [The `?`/_"Kleene"_ macro operator is now available in the 2015 edition.][60932] Compiler -------- - [You can now enable Profile-Guided Optimization with the `-C profile-generate` and `-C profile-use` flags.][61268] For more information on how to use profile guided optimization, please refer to the [rustc book][rustc-book-pgo]. - [The `rust-lldb` wrapper script should now work again.][61827] Libraries --------- - [`mem::MaybeUninit<T>` is now ABI-compatible with `T`.][61802] Stabilized APIs --------------- - [`BufReader::buffer`] - [`BufWriter::buffer`] - [`Cell::from_mut`] - [`Cell<[T]>::as_slice_of_cells`][`Cell<slice>::as_slice_of_cells`] - [`DoubleEndedIterator::nth_back`] - [`Option::xor`] - [`Wrapping::reverse_bits`] - [`i128::reverse_bits`] - [`i16::reverse_bits`] - [`i32::reverse_bits`] - [`i64::reverse_bits`] - [`i8::reverse_bits`] - [`isize::reverse_bits`] - [`slice::copy_within`] - [`u128::reverse_bits`] - [`u16::reverse_bits`] - [`u32::reverse_bits`] - [`u64::reverse_bits`] - [`u8::reverse_bits`] - [`usize::reverse_bits`] Cargo ----- - [`Cargo.lock` files are now included by default when publishing executable crates with executables.][cargo/7026] - [You can now specify `default-run="foo"` in `[package]` to specify the default executable to use for `cargo run`.][cargo/7056] Misc ---- Compatibility Notes ------------------- - [Using `...` for inclusive range patterns will now warn by default.][61342] Please transition your code to using the `..=` syntax for inclusive ranges instead. - [Using a trait object without the `dyn` will now warn by default.][61203] Please transition your code to use `dyn Trait` for trait objects instead. [62228]: rust-lang/rust#62228 [62235]: rust-lang/rust#62235 [61802]: rust-lang/rust#61802 [61827]: rust-lang/rust#61827 [61547]: rust-lang/rust#61547 [61682]: rust-lang/rust#61682 [61268]: rust-lang/rust#61268 [61342]: rust-lang/rust#61342 [61347]: rust-lang/rust#61347 [61100]: rust-lang/rust#61100 [61203]: rust-lang/rust#61203 [61229]: rust-lang/rust#61229 [60932]: rust-lang/rust#60932 [cargo/7026]: rust-lang/cargo#7026 [cargo/7056]: rust-lang/cargo#7056 [`BufReader::buffer`]: https://doc.rust-lang.org/std/io/struct.BufReader.html#method.buffer [`BufWriter::buffer`]: https://doc.rust-lang.org/std/io/struct.BufWriter.html#method.buffer [`Cell::from_mut`]: https://doc.rust-lang.org/std/cell/struct.Cell.html#method.from_mut [`Cell<slice>::as_slice_of_cells`]: https://doc.rust-lang.org/std/cell/struct.Cell.html#method.as_slice_of_cells [`DoubleEndedIterator::nth_back`]: https://doc.rust-lang.org/std/iter/trait.DoubleEndedIterator.html#method.nth_back [`Option::xor`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.xor [`RefCell::try_borrow_unguarded`]: https://doc.rust-lang.org/std/cell/struct.RefCell.html#method.try_borrow_unguarded [`Wrapping::reverse_bits`]: https://doc.rust-lang.org/std/num/struct.Wrapping.html#method.reverse_bits [`i128::reverse_bits`]: https://doc.rust-lang.org/std/primitive.i128.html#method.reverse_bits [`i16::reverse_bits`]: https://doc.rust-lang.org/std/primitive.i16.html#method.reverse_bits [`i32::reverse_bits`]: https://doc.rust-lang.org/std/primitive.i32.html#method.reverse_bits [`i64::reverse_bits`]: https://doc.rust-lang.org/std/primitive.i64.html#method.reverse_bits [`i8::reverse_bits`]: https://doc.rust-lang.org/std/primitive.i8.html#method.reverse_bits [`isize::reverse_bits`]: https://doc.rust-lang.org/std/primitive.isize.html#method.reverse_bits [`slice::copy_within`]: https://doc.rust-lang.org/std/primitive.slice.html#method.copy_within [`u128::reverse_bits`]: https://doc.rust-lang.org/std/primitive.u128.html#method.reverse_bits [`u16::reverse_bits`]: https://doc.rust-lang.org/std/primitive.u16.html#method.reverse_bits [`u32::reverse_bits`]: https://doc.rust-lang.org/std/primitive.u32.html#method.reverse_bits [`u64::reverse_bits`]: https://doc.rust-lang.org/std/primitive.u64.html#method.reverse_bits [`u8::reverse_bits`]: https://doc.rust-lang.org/std/primitive.u8.html#method.reverse_bits [`usize::reverse_bits`]: https://doc.rust-lang.org/std/primitive.usize.html#method.reverse_bits [rustc-book-pgo]: https://doc.rust-lang.org/rustc/profile-guided-optimization.html
Extend `#[must_use]` to nested structures Extends the `#[must_use]` lint to apply when `#[must_use]` types are nested within `struct`s (or one-variant `enum`s), making the lint much more generally useful. This is in line with #61100 extending the lint to tuples. Fixes #39524. cc @rust-lang/lang and @rust-lang/compiler for discussion in case this is a controversial change. In particular, we might want to consider allowing annotations on fields containing `#[must_use]` types in user-defined types (e.g. `#[allow(unused_must_use)]`) to opt out of this behaviour, if there are cases where we this this is likely to have frequent false positives. (This is based on top of #62235.)
Extend `#[must_use]` to nested structures Extends the `#[must_use]` lint to apply when `#[must_use]` types are nested within `struct`s (or one-variant `enum`s), making the lint much more generally useful. This is in line with #61100 extending the lint to tuples. Fixes #39524. cc @rust-lang/lang and @rust-lang/compiler for discussion in case this is a controversial change. In particular, we might want to consider allowing annotations on fields containing `#[must_use]` types in user-defined types (e.g. `#[allow(unused_must_use)]`) to opt out of this behaviour, if there are cases where we this this is likely to have frequent false positives. (This is based on top of #62235.)
Based on top of #62228.
r? @Centril