Move numeric consts to associated consts step1
A subset of #67913. Implements the first step of RFC https://github.com/rust-lang/rfcs/pull/2700
This PR adds the new constants as unstable constants and defines the old ones in terms of the new ones. Then fix a tiny bit of code that started having naming collisions because of the new assoc consts.
Removed a test that did not seem relevant any longer. Since doing just `u8::MIN` should now indeed be valid.
Document `From` implementation for NonZero nums
This is more of a nitpick than a real change in documentation. I did this for consistency with other documentation (namely Atomic integers).
Related to #51430
r? @steveklabnik
PS: I actually tested the code this time. My CPU died in the process, but I get to open a (hopefully 🤞) working PR
Document remaining undocumented `From` implementations for IPs
Some `From` implementations were missing documentation. I added examples, I tried to be as close to existing examples as possible.
Related to #51430 (cc @skade)
r? @steveklabnik
Use termize instead of term_size
`termize` is a fork of `term_size` which uses `winapi` 0.3 instead of 0.2. This is a step towards removing the `winapi` 0.2 dependency.
r? @Mark-Simulacrum
BTreeMap: tag and explain unsafe internal functions or assert preconditions
#68418 concluded that it's not desirable to tag all internal functions with preconditions as being unsafe. This PR does it to some functions, documents why, and elsewhere enforces the preconditions with asserts.
Implement clone_from for BTreeMap and BTreeSet
See #28481. This results in up to 90% speedups on simple data types when `self` and `other` are the same size, and is generally comparable or faster. Some concerns:
1. This implementation requires an `Ord` bound on the `Clone` implementation for `BTreeMap` and `BTreeSet`. Since these structs can only be created externally for keys with `Ord` implemented, this should be fine? If not, there's certainly a less safe way to do this.
2. Changing `next_unchecked` on `RangeMut` to return mutable key references allows for replacing the entire overlapping portion of both maps without changing the external interface in any way. However, if `clone_from` fails it can leave the `BTreeMap` in an invalid state, which might be unacceptable.
~This probably needs an FCP since it changes a trait bound, but (as far as I know?) that change cannot break any external code.~
Rollup of 7 pull requests
Successful merges:
- #67722 (Minor: note how Any is an unsafe trait in SAFETY comments)
- #68586 (Make conflicting_repr_hints a deny-by-default c-future-compat lint)
- #68598 (Fix null synthetic_implementors error)
- #68603 (Changelog: Demonstrate final build-override syntax)
- #68609 (Set lld flavor for MSVC to link.exe)
- #68611 (Correct ICE caused by macros generating invalid spans.)
- #68627 (Document that write_all will not call write if given an empty buffer)
Failed merges:
r? @ghost
Document that write_all will not call write if given an empty buffer
Some types of Write instances have a semantic meaning associated with
writing an empty buffer, such as sending an empty packet. This works
when calling `write` directly, and supplying an empty buffer. However,
calling `write_all` on an empty buffer will simply never call `write`,
because `write_all` assumes it has no work to do.
Document this behavior, to help prospective users of
datagram-packet-style Write instances.
Set lld flavor for MSVC to link.exe
This enables linking with LLD on Windows with just `-C linker=rust-lld` instead of needing `-C linker=rust-lld -C linker-flavor=lld-link`.
Minor: note how Any is an unsafe trait in SAFETY comments
Motivation: helpful to people like myself reading the standard library source to better understand how to use Any, especially if we do go ahead with https://github.com/rust-lang/rust/pull/67562 and make it an unsafe trait.
Detect use-after-scope bugs with AddressSanitizer
Enable use-after-scope checks by default when using AddressSanitizer.
They allow to detect incorrect use of stack objects after their scope
have already ended. The detection is based on LLVM lifetime intrinsics.
To facilitate the use of this functionality, the lifetime intrinsics are
now emitted regardless of optimization level if enabled sanitizer makes
use of them.
Some types of Write instances have a semantic meaning associated with
writing an empty buffer, such as sending an empty packet. This works
when calling `write` directly, and supplying an empty buffer. However,
calling `write_all` on an empty buffer will simply never call `write`,
because `write_all` assumes it has no work to do.
Document this behavior, to help prospective users of
datagram-packet-style Write instances.
Update links to WASI docs in time.rs module
Since the docs for the WASI API are now evolving in [WebAssembly/WASI] repo,
I thought it might be useful to update the links in the docs to point to that location
instead of using the outdated `CraneStation/wasmtime` destination.
[WebAssembly/WASI]: https://github.com/WebAssembly/WASI
r? @steveklabnik
cc @alexcrichton
rustdoc: Fix re-exporting primitive types
* Generate links to the primitive type docs for re-exports.
* Don't ICE on cross crate primitive type re-exports.
* Make primitive type re-exports show up cross crate.
Fixes#67646Closes#67972
r? @GuillaumeGomez
Don't ICE on path-collision in dep-graph
Collisions in the dep-graph due to path-reuse are rare but can occur.
So, instead of ICE'ing, just fail to mark green in such cases (for `DepKind::{Hir, HirBody, CrateMetadata}`).
Fix#62649.
Since the docs for the WASI API are now evolving in [WebAssembly/WASI] repo,
I thought it might be useful to update the links in the docs to point to that location
instead of using the outdated `CraneStation/wasmtime` destination.
[WebAssembly/WASI]: https://github.com/WebAssembly/WASI
