Added warning for unused arithmetic expressions
The compiler now displays a warning when a binary arithmetic operation is evaluated but not used. This resolves#50124 by following the instructions outlined in the issue. The changes are as follows:
- Added new pattern matching for unused arithmetic expressions in `src/librustc_lint/unused.rs`
- Added `#[must_use]` attributes to the binary operation methods in `src/libcore/internal_macros.rs`
- Added `#[must_use]` attributes to the non-assigning binary operators in `src/libcore/ops/arith.rs`
Move Range*::contains to a single default impl on RangeBounds
Per the ongoing discussion in #32311.
This is my first PR to Rust (woo!), so I don't know if this requires an amendment to the original range_contains RFC, or not, or if we can just do a psuedo-RFC here. While this may no longer follow the explicit decision made in that RFC, I believe this better follows its spirit by adding the new contains method to all Ranges. It also allows users to be generic over all ranges and use this method without writing it themselves (my personal desired use case).
This also somewhat answers the unanswered question about Wrapping ranges in the above issue by instead just punting it to the question of what those types should return for start() & end(), or if they should implement RangeArgument at all. Those types could also implement their own contains method without implementing this trait, in which case the question remains the same.
This does add a new contains method to types that already implemented RangeArgument but not contains. These types are RangeFull, (Bound<T>, Bound<T>), (Bound<&'a T>, Bound<&'a T>). No tests have been added for these types yet. No inherent method has been added either.
r? @alexcrichton
Operator traits seem to be inconsistent regarding the right hand side
generic. Most default Rhs/RHS to Self, but a few omit this. This patch
modifies them all to default to Self. This should not have any backwards
compatibility issues because we are only enabling code that previously
wouldn't compile.
Update ops range example to avoid confusion between indexes and values.
Makes clearer the numbers in the range refer to indexes, not the values at those indexes.
Add Range[Inclusive]::is_empty
During https://github.com/rust-lang/rfcs/pull/1980, it was discussed that figuring out whether a range is empty was subtle, and thus there should be a clear and obvious way to do it. It can't just be ExactSizeIterator::is_empty (also unstable) because not all ranges are ExactSize -- such as `Range<i64>` and `RangeInclusive<usize>`.
Things to ponder:
- Unless this is stabilized first, this makes stabilizing ExactSizeIterator::is_empty more icky, since this hides that.
- This is only on `Range` and `RangeInclusive`, as those are the only ones where it's interesting. But one could argue that it should be on more for consistency, or on RangeArgument instead.
- The bound on this is PartialOrd, since that works ok (see tests for float examples) and is consistent with `contains`. But ranges like `NAN..=NAN`_are_ kinda weird.
- [x] ~~There's not a real issue number on this yet~~
During the RFC, it was discussed that figuring out whether a range is empty was subtle, and thus there should be a clear and obvious way to do it. It can't just be ExactSizeIterator::is_empty (also unstable) because not all ranges are ExactSize -- not even Range<i32> or RangeInclusive<usize>.
- filter error on the evaluated value of `Self`
- filter error on the evaluated value of the type arguments
- add argument to include custom note in diagnostic
- allow the parser to parse `Self` when processing attributes
- add custom message to binops
