Mark it with the `unreachable` feature and put it into the `mem` module.
This is a pretty straight-forward API that can already be simulated in
stable Rust by using `transmute` to create an uninhabited enum that can
be matched.
Stabilize more APIs for the 1.20.0 release
In addition to the few stabilizations that have already landed, this cleans up the remaining APIs that are in `final-comment-period` right now to be stable by the 1.20.0 release
Make the "main" constructors of NonZero/Shared/Unique return Option
Per discussion in https://github.com/rust-lang/rust/issues/27730#issuecomment-303939441.
This is a breaking change to unstable APIs.
The old behavior is still available under the name `new_unchecked`. Note that only that one can be `const fn`, since `if` is currently not allowed in constant contexts.
In the case of `NonZero` this requires adding a new `is_zero` method to the `Zeroable` trait. I mildly dislike this, but it’s not much worse than having a `Zeroable` trait in the first place. `Zeroable` and `NonZero` are both unstable, this can be reworked later.
Bump master to 1.21.0
This commit bumps the master branch's version to 1.21.0 and also updates the
bootstrap compiler from the freshly minted beta release.
improve the TryFrom implementations
This removes the need for a 128 bit storage by making use of the fact that there can be either no over/underflow, either one or both, and each time the target type suffices to hold the limit for comparison. This also means that the implementation will work in targets without 128bit support (unless it's for 128bit types, of course).
The downside is that the code looks a bit more complex.
This removes the need for a 128 bit storage by making use of the fact that
there can be either no over/underflow, either one or both, and each time
the target type suffices to hold the limit for comparison.
The downside is that the code looks a bit more complex.
This test code included in this commit is from @oyvindln 's PR. They also
greatly helped fixing a number of errors I made along the way. Thanks a lot!
Add generic example of std::ops::Sub in doc comments
This PR adds an example of using generics with std::ops::Sub and is a follow up of PR #41612 and is related to issue #29365. I also wanted to add examples to Mul and Div, but I think these two traits are already loaded with examples.
std: Cut down #[inline] annotations where not necessary
This PR cuts down on a large number of `#[inline(always)]` and `#[inline]`
annotations in libcore for various core functions. The `#[inline(always)]`
annotation is almost never needed and is detrimental to debug build times as it
forces LLVM to perform inlining when it otherwise wouldn't need to in debug
builds. Additionally `#[inline]` is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units and otherwise rarely needs the extra "help" from us to tell LLVM
to inline something.
Overall this PR cut the compile time of a [microbenchmark][1] by 30% from 1s to
0.7s.
[1]: https://gist.github.com/alexcrichton/a7d70319a45aa60cf36a6a7bf540dd3a
This PR cuts down on a large number of `#[inline(always)]` and `#[inline]`
annotations in libcore for various core functions. The `#[inline(always)]`
annotation is almost never needed and is detrimental to debug build times as it
forces LLVM to perform inlining when it otherwise wouldn't need to in debug
builds. Additionally `#[inline]` is an unnecessary annoation on almost all
generic functions because the function will already be monomorphized into other
codegen units and otherwise rarely needs the extra "help" from us to tell LLVM
to inline something.
Overall this PR cut the compile time of a [microbenchmark][1] by 30% from 1s to
0.7s.
[1]: https://gist.github.com/alexcrichton/a7d70319a45aa60cf36a6a7bf540dd3a
Workaround "Quasi-quoting is inefficient" warning in incremental rustbuild introduced in #43252.
After #43252 is merged, building stage0 libcore with `-i` (`--incremental`) flag will cause 17 "Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)" warnings, as in #40946.
```
warning: Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)
--> src/libcore/default.rs:133:21
|
133 | #[doc = $doc]
| ^^^^
...
139 | default_impl! { (), (), "Returns the default value of `()`" }
| ------------------------------------------------------------- in this macro invocation
(× 17)
```
True fix for #40946 will take at least 12 weeks from now to make into the next stage0, so it is quicker to workaround it in libcore instead.
cc @vbrandl @jseyfried
