| Age | Commit message (Collapse) | Author | Lines |
|---|
|
tests were failing because I didn't wrap code snippets like in backticks. fixed that now, so hopefully tests will pass on travis
|
|
This trait is more-or-less the reverse of CoerceUnsized, and will be
used for object-safety checks. Receiver types like `Rc` will have to
implement `CoerceSized` so that methods that use `Rc<Self>` as the
receiver will be considered object-safe.
|
|
* Also update the bootstrap compiler
* Update cargo to 1.32.0
* Clean out stage0 annotations
|
|
|
|
|
|
|
|
|
|
RfC -> RFC
|
|
|
|
When the index is not PartialOrd, always treat the range as empty.
|
|
Fix #45222.
|
|
|
|
rename RangeBounds::start() -> start_bound()
rename RangeBounds::end() -> end_bound()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Added new()/start()/end() methods to RangeInclusive.
Changed the lowering of `..=` to use RangeInclusive::new().
|
|
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`
|
|
|
|
|
|
|
|
Update Rhs on ShlAssign to default to Self
This matches the behavior on ShrAssign and all other *Assign operations.
|
|
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.
|
|
Closes #22181, #27779
|
|
|
|
Explicitly mention `Option` in `?` error message.
Save users the time/effort of having to lookup what types implement
the `Try` trait.
|
|
|
|
These unstable items are deprecated:
* The `std::collections::range::RangeArgument` reexport
* The `std::collections::range` module.
|
|
The stable reexport `std::collections::Bound` is now deprecated.
Another deprecated reexport could be added in `alloc`,
but that crate is unstable.
|
|
Save users the time/effort of having to lookup what types implement
the `Try` trait.
|
|
generators. Fixes #47787
|
|
|
|
Stabilize the syntax `a..=b` and `..=b`.
|
|
Stabilize std::ops::RangeInclusive and std::ops::RangeInclusiveTo.
|
|
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~~
|
|
|
|
|
|
|
|
|
