`wrapping_shl` and `wrapping_shr` are easy to mistake for rotations, when in fact they work somewhat differently. The documentation currently available is a little sparse and easy to misinterpret, so I've added a warning to anyone who bumps into them that the equivalent rotate methods may actually be what they're looking for.
If it's deemed useful to add a symmetrical mention to the documentation for the `rotate_left` and `rotate_right` methods, I can certainly have a go at that, but my gut feeling is that people likely to want a rotate will already know about the wrapping-arithmetic methods, for example from writing CPU simulators.
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
This commit does two things:
* Re-works the module-level documentation.
* Cleaning up wording and adding links to where error types are used.
Part of #29364
This commit does two things:
* Re-works the module-level documentation.
* Cleaning up wording and adding links to where error types are used.
Part of #29364
Since a lexicographic ordering of a struct could vary based on which struct members are compared first, I ended up doing some testing to ensure that the behavior when deriving these traits was what I expected (ordered based on the top to bottom order of declaration of the members). I wanted to add this little bit of documentation to potentially save someone else the same effort. That is, assuming that my testing correctly reflects the intended behavior of the compiler.
r? @steveklabnik
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
Issue #31109 uncovered two semi-related problems:
* A panic in `str::parse::<f64>`
* A panic in `rustc::middle::const_eval::lit_to_const` where the result of float parsing was unwrapped.
This series of commits fixes both issues and also drive-by-fixes some things I noticed while tracking down the parsing panic.
This is a behavior that some find confusing, so it deserves its own example.
Fixes#31318
I think this wording might be a bit strange, but I couldn't come up with anything better. Feedback very welcome.
This commit transitions the compiler to using the new exception handling
instructions in LLVM for implementing unwinding for MSVC. This affects both 32
and 64-bit MSVC as they're both now using SEH-based strategies. In terms of
standard library support, lots more details about how SEH unwinding is
implemented can be found in the commits.
In terms of trans, this change necessitated a few modifications:
* Branches were added to detect when the old landingpad instruction is used or
the new cleanuppad instruction is used to `trans::cleanup`.
* The return value from `cleanuppad` is not stored in an `alloca` (because it
cannot be).
* Each block in trans now has an `Option<LandingPad>` instead of `is_lpad: bool`
for indicating whether it's in a landing pad or not. The new exception
handling intrinsics require that on MSVC each `call` inside of a landing pad
is annotated with which landing pad that it's in. This change to the basic
block means that whenever a `call` or `invoke` instruction is generated we
know whether to annotate it as part of a cleanuppad or not.
* Lots of modifications were made to the instruction builders to construct the
new instructions as well as pass the tagging information for the call/invoke
instructions.
* The translation of the `try` intrinsics for MSVC has been overhauled to use
the new `catchpad` instruction. The filter function is now also a
rustc-generated function instead of a purely libstd-defined function. The
libstd definition still exists, it just has a stable ABI across architectures
and leaves some of the really weird implementation details to the compiler
(e.g. the `localescape` and `localrecover` intrinsics).
This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.
Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today
This commit implements the stabilization of the custom hasher support intended
for 1.7 but left out due to some last-minute questions that needed some
decisions. A summary of the actions done in this PR are:
Stable
* `std:#️⃣:BuildHasher`
* `BuildHasher::Hasher`
* `BuildHasher::build_hasher`
* `std:#️⃣:BuildHasherDefault`
* `HashMap::with_hasher`
* `HashMap::with_capacity_and_hasher`
* `HashSet::with_hasher`
* `HashSet::with_capacity_and_hasher`
* `std::collections::hash_map::RandomState`
* `RandomState::new`
Deprecated
* `std::collections::hash_state`
* `std::collections::hash_state::HashState` - this trait was also moved into
`std::hash` with a reexport here to ensure that we can have a blanket impl to
prevent immediate breakage on nightly. Note that this is unstable in both
location.
* `HashMap::with_hash_state` - renamed
* `HashMap::with_capacity_and_hash_state` - renamed
* `HashSet::with_hash_state` - renamed
* `HashSet::with_capacity_and_hash_state` - renamed
Closes#27713
This commit implements the stabilization of the custom hasher support intended
for 1.7 but left out due to some last-minute questions that needed some
decisions. A summary of the actions done in this PR are:
Stable
* `std:#️⃣:BuildHasher`
* `BuildHasher::Hasher`
* `BuildHasher::build_hasher`
* `std:#️⃣:BuildHasherDefault`
* `HashMap::with_hasher`
* `HashMap::with_capacity_and_hasher`
* `HashSet::with_hasher`
* `HashSet::with_capacity_and_hasher`
* `std::collections::hash_map::RandomState`
* `RandomState::new`
Deprecated
* `std::collections::hash_state`
* `std::collections::hash_state::HashState` - this trait was also moved into
`std::hash` with a reexport here to ensure that we can have a blanket impl to
prevent immediate breakage on nightly. Note that this is unstable in both
location.
* `HashMap::with_hash_state` - renamed
* `HashMap::with_capacity_and_hash_state` - renamed
* `HashSet::with_hash_state` - renamed
* `HashSet::with_capacity_and_hash_state` - renamed
Closes#27713
The previous example did not do what its description said. In it panicked on integer overflow in debug mode, and went into an infinite loop in release mode (wrapping back to 0 after printing 254).
