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
compiletest: Unit tests for `EarlyProps` (+ small cleanup)
* Parse `EarlyProps` from a reader
* Add unit tests for `EarlyProps`
* Remove unused `llvm-cxxflags` option
* Remove unnecessary memory allocations in `iter_header`
* Update mode list displayed in `--help`
This patch enables rustc to emit the required LLVM module flags to enable Control Flow Guard metadata (cfguard=1) or metadata and checks (cfguard=2). The LLVM module flags are ignored on unsupported targets and operating systems.
Rename `Alloc` to `AllocRef`
The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958.
This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors.
For further explanation please see https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 and the comments after that one.
Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle.
The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing.
Blocked on https://github.com/rust-lang/miri/pull/1160
Mainly for API parity with HashMap.
- Add BTreeMap::remove_entry
- Rewrite BTreeMap::remove to use remove_entry
- Use btreemap_remove_entry feature in doc comment
Stabilize ptr::slice_from_raw_parts[_mut]
Closes#36925, the tracking issue.
Initial impl: #60667
r? @rust-lang/libs
In addition to stabilizing, I've adjusted the example of `ptr::slice_from_raw_parts` to use `slice_from_raw_parts` instead of `slice_from_raw_parts_mut`, which was unnecessary for the example as written.
check_match: extract common logic
This is part of work on `hir::ExprKind::Let` which I thought made sense on its own (though makes even more sense with `::Let`).
r? @oli-obk
Bump LLVM submodule to fix LLVM assertion failure in MSP430 interrupt generation.
This PR brings in changes introduced by [this cherry-pick](https://github.com/rust-lang/llvm-project/pull/37) to the Rust repository.
Nightlies downloaded from `rustup` do not appear to have llvm assertions enabled; the assertion failure [sometimes](https://github.com/YuhanLiin/msp430fr2355-quickstart/issues/3) causes link errors that shouldn't occur. I couldn't find any indication of other bugs; however, it should still be fixed.
