Rollup of 7 pull requests
Successful merges:
- #80011 (Stabilize `peekable_next_if`)
- #81580 (Document how `MaybeUninit<Struct>` can be initialized.)
- #81610 (BTreeMap: make Ord bound explicit, compile-test its absence)
- #81664 (Avoid a hir access inside get_static)
- #81675 (Make rustdoc respect `--error-format short` in doctests)
- #81753 (Never MIR inline functions with a different instruction set)
- #81795 (Small refactor with Iterator::reduce)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make rustdoc respect `--error-format short` in doctests
Note that this will not work with `cargo test`, only with `rustdoc --test`, I'll have to modify `cargo` as well.
Fix#81662.
`@rustbot` label +T-rustdoc +A-doctests
Avoid a hir access inside get_static
Together with #81056 this ensures that the codegen unit DepNode doesn't have a direct dependency on any part of the hir.
BTreeMap: make Ord bound explicit, compile-test its absence
Most `BTreeMap` and `BTreeSet` members are subject to an `Ord` bound but a fair number of methods are not. To better convey and perhaps later tune the `Ord` bound, make it stand out in individual `where` clauses, instead of once far away at the beginning of an `impl` block. This PR does not introduce or remove any bounds.
Also adds compilation test cases checking that the bound doesn't creep in unintended on the historically unbounded methods.
Fix rustc sysroot in systems using CAS
Change filesearch::get_or_default_sysroot() to check if sysroot is found using env::args().next() if rustc in argv[0] is a symlink; otherwise, or if it is not found, use env::current_exe() to imply sysroot. This makes the rustc binary able to locate Rust libraries in systems using content-addressable storage (CAS).
Encode MIR metadata by iterating on DefId instead of traversing the HIR tree
Split out of https://github.com/rust-lang/rust/pull/80347.
This part only traverses `mir_keys` and encodes MIR according to the def kind.
r? `@oli-obk`
Revert 78373 ("dont leak return value after panic in drop")
Short term resolution for issue #80949.
Reopen#47949 after this lands.
(We plan to fine-tune PR #78373 to not run into this problem.)
Rollup of 15 pull requests
Successful merges:
- #79554 (Generic associated types in trait paths)
- #80726 (relax adt unsizing requirements)
- #81307 (Handle `Span`s for byte and raw strings and add more detail )
- #81318 (rustdoc-json: Fix has_body)
- #81456 (Make remote-test-server easier to use with new targets)
- #81497 (rustdoc: Move `display_fn` struct inside `display_fn`)
- #81500 (Remove struct_type from union output)
- #81542 (Expose correct symlink API on WASI)
- #81676 (Add more information to the error code for 'crate not found')
- #81682 (Add additional bitset benchmarks)
- #81730 (Make `Allocator` object-safe)
- #81763 (Cleanup rustdoc pass descriptions a bit)
- #81767 (Update LayoutError/LayoutErr stability attributes)
- #81771 (Indicate change in RSS from start to end of pass in time-passes output)
- #81781 (Fix `install-awscli.sh` error in CI)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Indicate change in RSS from start to end of pass in time-passes output
Previously, this was omitted because it could be misleading, but the
functionality seems too useful not to include.
r? ``@oli-obk``
Update LayoutError/LayoutErr stability attributes
`LayoutError` ended up not making it into 1.49.0, updating the stability attributes to reflect that.
I also pushed `LayoutErr` deprecation back a release to allow 2 releases before the deprecation comes into effect.
This change should be backported to beta.
Cleanup rustdoc pass descriptions a bit
Also changed a couple of comments from "intra-doc-links" to
"intra-doc links" (my understanding is that "intra-doc links" is the
standard way to refer to them).
Add additional bitset benchmarks
Add additional benchmarks for operations in bitset, I realize that it was a bit lacking when I intended to optimize it earlier, so I was hoping to put some in so I can verify my work later.
Expose correct symlink API on WASI
As described in https://github.com/rust-lang/rust/issues/68574, the currently exposed API for symlinks is, in fact, a thin wrapper around the corresponding syscall, and not suitable for public usage.
The reason is that the 2nd param in the call is expected to be a handle of a "preopened directory" (a WASI concept for exposing dirs), and the only way to retrieve such handle right now is by tinkering with a private `__wasilibc_find_relpath` API, which is an implementation detail and definitely not something we want users to call directly.
Making matters worse, the semantics of this param aren't obvious from its name (`fd`), and easy to misinterpret, resulting in people trying to pass a handle of the target file itself (as in https://github.com/vitiral/path_abs/pull/50), which doesn't work as expected.
I did a [codesearch among open-source repos](https://sourcegraph.com/search?q=std%3A%3Aos%3A%3Awasi%3A%3Afs%3A%3Asymlink&patternType=literal), and the usage above is so far the only usage of this API at all, but we should fix it before more people start using it incorrectly.
While this is technically a breaking API change, I believe it's a justified one, as 1) it's OS-specific and 2) there was strictly no way to correctly use the previous form of the API, and if someone does use it, they're likely doing it wrong like in the example above.
The new API does not lead to the same confusion, as it mirrors `std::os::unix::fs::symlink` and `std::os::windows::fs::symlink_{file,dir}` variants by accepting source/target paths.
Fixes#68574.
r? ``@alexcrichton``
Remove struct_type from union output
Also bumps the format number and adds a test
Rationale: It's illegal to have unions of the form `union Union(i32, f32);`, or `union Union;`. The struct_type field was recently removed from the rustdoc Union AST, at which time this field was changed to always just read "union". It makes sense to completely remove it, as it provides no information.
rustdoc: Move `display_fn` struct inside `display_fn`
This makes it clear that it's an implementation detail of `display_fn`
and shouldn't be used elsewhere, and it enforces in the compiler that no
one else can use it.
r? ````@GuillaumeGomez````
Make remote-test-server easier to use with new targets
While testing #81455 I encountered 2 issues with `remote-test-server`:
- It is built with the stage 0 toolchain, which does not support a newly added target.
- It overwrites `LD_LIBRARY_PATH` instead of appending to it, which prevents the use of a custom sysroot for target libraries.
rustdoc-json: Fix has_body
Previously, `has_body` was always true. Now propagate the type of the method to set it correctly. Relies on #81287, that will need to be merged first.
relax adt unsizing requirements
Changes unsizing of structs in case the last struct field shares generic params with other adt fields which do not change.
This change is currently insta stable and changes the language, so it at least requires a lang fcp. I feel like the current state is fairly unintuitive.
An example for what's now allowed would be https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6dd331d23f5c9ffc8c978175aae2e967
```rust
struct A<T, U: ?Sized>(T, B<T, U>); // previously ERR
// struct A<T, U: ?Sized>(T, B<[u32; 1], U>); // ok
struct B<T, U: ?Sized>(T, U);
fn main() {
let x = A([0; 1], B([0; 1], [0; 1]));
let y: &A<[u32; 1], [u32]> = &x;
assert_eq!(y.1.1.len(), 1);
}
```
rustc_codegen_ssa: tune codegen scheduling to reduce memory usage
For better throughput during parallel processing by LLVM, we used to sort
CGUs largest to smallest. This would lead to better thread utilization
by, for example, preventing a large CGU from being processed last and
having only one LLVM thread working while the rest remained idle.
However, this strategy would lead to high memory usage, as it meant the
LLVM-IR for all of the largest CGUs would be resident in memory at once.
Instead, we can compromise by ordering CGUs such that the largest and
smallest are first, second largest and smallest are next, etc. If there
are large size variations, this can reduce memory usage significantly.
Use `# min-llvm-version: 11.0` to force a minimum LLVM version
Use `# min-llvm-version: 11.0` to force a minimum LLVM version, rather than ad-hoc internal solution.
In particular: the specific code to define LLVM_VERSION_11_PLUS here was, for some reason, using `$(shell ...)` with bash-specific variable replacement code. On non-bash platforms like dash, that `shell` invocation would fail, and the
LLVM_VERSION_11_PLUS check would always fail, the test would always be ignored, and thus be treated as a "success" (in the sense that `--bless` would never do anything).
* Note in particular that GNU Make treats the SHELL variable as a very special case: it does not inherit the value of SHELL from the user's environment. Except on Windows. See more explanation in the [GNU Make docs](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html).
* The effect of this is that these tests end up using `/bin/sh` (except on Windows) for their `$(shell ...)` invocations, and thus we see differing behaviors depending on whether your `/bin/sh` links to `/bin/dash` or to `/bin/bash`.
This was causing me a lot of pain.