slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts
This fixes the problem that we are fabricating pointers out of thin air. I also managed to share more code between the mutable and shared iterators, while reducing the amount of macros.
I am not sure how useful it really is to add a `debug_assert!` in libcore. Everybody gets a release version of that anyway, right? Is there at least a CI job that runs the test suite with a debug version?
Fixes#42789
Rollup of 15 pull requests
Successful merges:
- #52793 (Add test for NLL: unexpected "free region `` does not outlive" error )
- #52799 (Use BitVector for global sets of AttrId)
- #52809 (Add test for unexpected region for local data ReStatic)
- #52834 ([NLL] Allow conflicting borrows of promoted length zero arrays)
- #52835 (Fix Alias intra doc ICE)
- #52854 (fix memrchr in miri)
- #52899 (tests/ui: Add missing mips{64} ignores)
- #52908 (Use SetLenOnDrop in Vec::truncate())
- #52915 (Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator)
- #52926 (rustc: Trim down the `rust_2018_idioms` lint group)
- #52930 (rustc_resolve: record single-segment extern crate import resolutions.)
- #52939 (Make io::Read::read_to_end consider io::Take::limit)
- #52942 (Another SmallVec.extend optimization)
- #52947 (1.27 actually added the `armv5te-unknown-linux-musleabi` target)
- #52954 (async can begin expressions)
Failed merges:
r? @ghost
1.27 actually added the `armv5te-unknown-linux-musleabi` target
The PR title says `armv5te-unknown-linux-musl`, but it looks like the final code merge renamed the target to `armv5te-unknown-linux-musleabi`. `rustup` reports this as correct as well.
The [Rust Platform Support](https://forge.rust-lang.org/platform-support.html) page needs this added as well, but I'm not certain what codebase that is generated from.
Make io::Read::read_to_end consider io::Take::limit
Add a custom implementation of `io::Read::read_to_end` for `io::Take` that doesn't reserve the default 32 bytes but rather `Take::limit` if `Take::limit < 32`.
It's a conservative adjustment that preserves the default behavior for `Take::limit >= 32`.
Fixes#51746.
rustc_resolve: record single-segment extern crate import resolutions.
Fixes#52489 by recording special-cased single-segment imports for later (e.g. stability) checks.
cc @alexcrichton @Mark-Simulacrum @petrochenkov
Does this need to be backported?
rustc: Trim down the `rust_2018_idioms` lint group
These migration lints aren't all up to par in terms of a good migration
experience. Some, like `unreachable_pub`, hit bugs like #52665 and unprepared
macros to be handled enough of the time. Others like linting against
`#[macro_use]` are swimming upstream in an ecosystem that's not quite ready (and
slightly buggy pending a few current PRs).
The general idea is that we will continue to recommend the `rust_2018_idioms`
lint group as part of the transition guide (as an optional step) but we'll be
much more selective about which lints make it into this group. Only those with a
strong track record of not causing too much churn will make the cut.
cc #52679
fix memrchr in miri
The previous PR https://github.com/rust-lang/rust/pull/52744 was not enough because it assumed that the split between the `mid` and `end` parts returned by `align_to` was aligned. But really the only guarantee we have is that the `mid` part is aligned, so make use of that.
[NLL] Allow conflicting borrows of promoted length zero arrays
This is currently overkill as there's no way to create two conflicting borrows of any promoted.
It is possible that the following code might not fail due to const eval in the future (@oli-obk?). In which case either the array marked needs to not be promoted, or to be checked for conflicts
```rust
static mut A: () = {
let mut y = None;
let z;
let mut done_y = false;
loop {
let x = &mut [1]; // < this array
if done_y {
z = x;
break;
}
y = Some(x);
done_y = true;
}
some_const_fn(y, z); // some_const_fn expects that y to not alias z.
};
```
r? @pnkfelix @nikomatsakis
closes#52671
cc #51823
The PR title says `armv5te-unknown-linux-musl`, but it looks like the final code merge renamed the target to `armv5te-unknown-linux-musleabi`. `rustup` reports this as correct as well.
The [Rust Platform Support](https://forge.rust-lang.org/platform-support.html) page needs this added as well, but I'm not certain what codebase that is generated from.
These migration lints aren't all up to par in terms of a good migration
experience. Some, like `unreachable_pub`, hit bugs like #52665 and unprepared
macros to be handled enough of the time. Others like linting against
`#[macro_use]` are swimming upstream in an ecosystem that's not quite ready (and
slightly buggy pending a few current PRs).
The general idea is that we will continue to recommend the `rust_2018_idioms`
lint group as part of the transition guide (as an optional step) but we'll be
much more selective about which lints make it into this group. Only those with a
strong track record of not causing too much churn will make the cut.
cc #52679
rustc: Handle linker diagnostics from LLVM
Previously linker diagnostic were being hidden when two modules were linked
together but failed to link. This commit fixes the situation by ensuring that we
have a diagnostic handler installed and also adds support for handling linker
diagnostics.
Rollup of 30 pull requests
Successful merges:
- #52340 (Document From trait implementations for OsStr, OsString, CString, and CStr)
- #52628 (Cleanup some rustdoc code)
- #52732 (Remove unstable and deprecated APIs)
- #52745 (Update clippy to latest master)
- #52771 (Clarify thread::park semantics)
- #52778 (Improve readability of serialize.rs)
- #52810 ([NLL] Don't make "fake" match variables mutable)
- #52821 (pretty print for std::collections::vecdeque)
- #52822 (Fix From<LocalWaker>)
- #52824 (Fix -Wpessimizing-move warnings in rustllvm/PassWrapper)
- #52825 (Make sure #47772 does not regress)
- #52831 (remove references to AUTHORS.txt file)
- #52842 (update comment)
- #52846 (Add timeout to use of `curl` in bootstrap.py.)
- #52851 (Make the tool_lints actually usable)
- #52853 (Improve bootstrap help on stages)
- #52859 (Use Vec::extend in SmallVec::extend when applicable)
- #52861 (Add targets for HermitCore (https://hermitcore.org) to the Rust compiler and port libstd to it.)
- #52867 (releases.md: fix 2 typos)
- #52870 (Implement Unpin for FutureObj and LocalFutureObj)
- #52876 (run-pass/const-endianness: negate before to_le())
- #52878 (Fix wrong issue number in the test name)
- #52883 (Include lifetime in mutability suggestion in NLL messages)
- #52888 (Use suggestions for shell format arguments)
- #52904 (NLL: sort diagnostics by span)
- #52905 (Fix a typo in unsize.rs)
- #52907 (NLL: On "cannot move out of type" error, print original before rewrite)
- #52914 (Only run the sparc-abi test on sparc)
- #52918 (Backport 1.27.2 release notes)
- #52929 (Update compatibility note for 1.28.0 to be correct)
Failed merges:
r? @ghost
Update compatibility note for 1.28.0 to be correct
You can still put implementations on `dyn Trait + Send + Send`, but it'd be the same as putting them on `dyn Trait + Send`. This is why the error is that there are duplicate definitions in the example.
Only run the sparc-abi test on sparc
It is not required for LLVM to have SPARC target support, so it is
necessary to only run this test when LLVM does support SPARC. Sadly, it
isn’t possible to specify exactly this constraint. Instead, we specify
that this test should run on SPARC host only (it surely is sane
assumption to make that compiler running on a SPARC can generate
SPARC, right?)
Since you cannot specify multiple `only-*` to have it run on both 32-bit
and 64-bit SPARC we pick 64-bit SPARC, because it is exactly what is
being tested by this test.
Fixes#52881
NLL: On "cannot move out of type" error, print original before rewrite
NLL: On "cannot move out of type" error, print original source before rewrite.
* Arguably this change is sometimes injecting noise into the output (namely in the cases where the suggested rewrite is inline with the suggestion and we end up highlighting the original source code). I would not be opposed to something more aggressive/dynamic, like revising the suggestion code to automatically print the original source when necessary (e.g. when the error does not have a span that includes the span of the suggestion).
* Also, as another note on this change: The doc comment for `Diagnostic::span_suggestion` says:
```rust
/// The message
///
/// * should not end in any punctuation (a `:` is added automatically)
/// * should not be a question
/// * should not contain any parts like "the following", "as shown"
```
* but the `:` is *not* added when the emitted line appears out-of-line relative to the suggestion. I find that to be an unfortunate UI experience.
----
As a drive-by fix, also changed code to combine multiple suggestions for a pattern into a single multipart suggestion (which vastly improves user experience IMO).
----
Includes the updates to expected NLL diagnostics.
Fix#52877
NLL: sort diagnostics by span
Sorting the output diagnostics by span is a long planned revision to the NLL diagnostics that we hope will yield a less surprising user experience in some case.
Once we got them buffered, it was trivial to implement. (The hard part is skimming the resulting changes to the diagnostics to make sure nothing broke... Note that I largely rubber-stamped the `#[rustc_regions]` output change.)
Fix#51167
