Rollup of 10 pull requests
Successful merges:
- #122707 (Fix a typo in the alloc::string::String docs)
- #122769 (extend comments for reachability set computation)
- #122892 (fix(bootstrap/dist): use versioned dirs when vendoring)
- #122896 (Update stdarch submodule)
- #122923 (In `pretty_print_type()`, print `async fn` futures' paths instead of spans.)
- #122950 (Add regression tests for #101903)
- #123039 (Update books)
- #123042 (Import the 2021 prelude in the core crate)
- #123044 (`Instance` is `Copy`)
- #123051 (did I mention that tests are super cool? )
r? `@ghost`
`@rustbot` modify labels: rollup
Print a backtrace in const eval if interrupted
Demo:
```rust
#![feature(const_eval_limit)]
#![const_eval_limit = "0"]
const OW: u64 = {
let mut res: u64 = 0;
let mut i = 0;
while i < u64::MAX {
res = res.wrapping_add(i);
i += 1;
}
res
};
fn main() {
println!("{}", OW);
}
```
```
╭ ➜ ben@archlinux:~/rust
╰ ➤ rustc +stage1 spin.rs
^Cerror[E0080]: evaluation of constant value failed
--> spin.rs:8:33
|
8 | res = res.wrapping_add(i);
| ^ Compilation was interrupted
note: erroneous constant used
--> spin.rs:15:20
|
15 | println!("{}", OW);
| ^^
note: erroneous constant used
--> spin.rs:15:20
|
15 | println!("{}", OW);
| ^^
|
= note: this note originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to previous error
For more information about this error, try `rustc --explain E0080`.
```
`Instance` is `Copy`
No reason to take it by value; it was confusing ``@rcvalle`` to see it being mutated when it's also being passed by ref in some places.
Import the 2021 prelude in the core crate
The `core` crate currently imports the v1 prelude
b3df0d7e5e/library/core/src/lib.rs (L285-L287)
This recently caused an issue when updating the `portable-simd` subtree since it was using a trait that was added to the 2021 prelude: https://github.com/rust-lang/rust/pull/122905#discussion_r1536228822
To make it easier to have a consistent build environment for subtrees and submodules that get included in `core`, we will now import the 2021 prelude into `core`.
Fixes#122912
r? `@Nilstrieb`
In `pretty_print_type()`, print `async fn` futures' paths instead of spans.
This makes `-Zprint-type-sizes`'s output easier to read, because the name of an `async fn` is more immediately recognizable than its span. This change will also synergize with my other `-Zprint-type-sizes` PR #122922 which prints the type of child futures being awaited.
I also deleted the comment "FIXME(eddyb) should use `def_span`." because it appears to have already been fixed by commit 67727aa7c3.
fix(bootstrap/dist): use versioned dirs when vendoring
Currently, if you attempt to run ui tests in a vendored build, you will
see this failure
```
---- [ui] tests/ui/issues/issue-21763.rs stdout ----
diff of stderr:
8 = note: required because it appears within the type `(Rc<()>, Rc<()>)`
9 = note: required for `hashbrown::raw::RawTable<(Rc<()>, Rc<()>)>` to implement `Send`
10 note: required because it appears within the type `hashbrown::map::HashMap<Rc<()>, Rc<()>, RandomState>`
- --> $HASHBROWN_SRC_LOCATION
+ --> /rust/deps/hashbrown/src/map.rs:190:12
12 note: required because it appears within the type `HashMap<Rc<()>, Rc<()>>`
13 --> $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
14 note: required by a bound in `foo`
```
This happens because the code that attempts to remap
`HASHBROWN_SRC_LOCATION` expects it to be under `hashbrown-$version`,
which is the case in a normal cargo registry, but not when vendoring, where
by default crates may not have the version in their directory name.
This change passes `--versioned-dirs` to `cargo vendor` to enforce that
every crate includes the version in the subdir name, which fixes the ui
test and brings `--enable-vendor` builds closer to normal ones.
Rollup of 9 pull requests
Successful merges:
- #122842 (Don't emit an error about failing to produce a file with a specific name if user never gave an explicit name)
- #122881 (Delegation: fix ICE on `bound_vars` divergence)
- #122910 (Validate that we're only matching on unit struct for path pattern)
- #122970 (Use `chunk_by` when building `ReverseSccGraph`)
- #122988 (add even more tests! )
- #122999 (Fix unpretty UI test when /tmp does not exist)
- #123001 (Rename `{enter,exit}_lint_attrs` to `check_attributes{,_post}`)
- #123022 (Add `async-closures/once.rs` back to cranelift tests)
- #123034 (Add a bunch of needs-unwind annotations to tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Rename `{enter,exit}_lint_attrs` to `check_attributes{,_post}`
Several places in Clippy want to check all the attributes of a node, we end up using `hir().attrs()` from several different `check_` functions (e.g. [in our doc lints](95c62ffae9/clippy_lints/src/doc/mod.rs (L396))) but this is error prone, we recently found that doc lints weren't triggering on struct fields for example
I went to add a `check_attributes` function but realised `enter_lint_attrs` is already this, the rename is to encourage their use
Also removes `LateContextAndPass::visit_attribute` since it's unused - `visit_attribute` for HIR visitors is only called by `hir().walk_attributes()` which lint passes do not use
Validate that we're only matching on unit struct for path pattern
Resolution doesn't validate that we only really take `CtorKind::Unit` in path patterns, since all it sees is `Res::SelfCtor(def_id)`. Check this instead during pattern typeck.
r? petrochenkov
Fixes#122809
Delegation: fix ICE on `bound_vars` divergence
Fixes https://github.com/rust-lang/rust/issues/122550.
Bug was caused by divergence between lowered type and corresponding `bound_vars` in `late_bound_vars_map`. In this patch `bound_vars` calculation for delegation item is moved from `lower_fn_ty` to `resolve_bound_vars` query.
r? `@petrochenkov`
Don't emit an error about failing to produce a file with a specific name if user never gave an explicit name
Fixes#122509
You can ask `rustc` to produce some intermediate results with `--emit foo`, this operation comes in two flavors: `--emit asm` and `--emit asm=foo.s`. First one produces one or more `.s` files without any name guarantees, second one renames it into `foo.s`. Second version only works when compiler produces a single file - for asm files this means using a single compilation unit for example.
In case compilation produced more than a single file `rustc` runs following check to emit some warnings:
```rust
if crate_output.outputs.contains_key(&output_type) {
// 2) Multiple codegen units, with `--emit foo=some_name`. We have
// no good solution for this case, so warn the user.
sess.dcx().emit_warn(errors::IgnoringEmitPath { extension });
} else if crate_output.single_output_file.is_some() {
// 3) Multiple codegen units, with `-o some_name`. We have
// no good solution for this case, so warn the user.
sess.dcx().emit_warn(errors::IgnoringOutput { extension });
} else {
// 4) Multiple codegen units, but no explicit name. We
// just leave the `foo.0.x` files in place.
// (We don't have to do any work in this case.)
}
```
Comment in the final `else` branch implies that if user didn't ask for a specific name - there's no need to emit warnings. However because of the internal representation of `crate_output.outputs` - this doesn't work as expected: if user asked to produce an asm file without giving it an implicit name it will contain `Some(None)`.
To fix the problem new code actually checks if user gave an explicit name. I think this was an original intentional behavior, at least comments imply that.
This makes `-Zprint-type-sizes`'s output easier to read, because the
name of an `async fn` is more immediately recognizable than its span.
I also deleted the comment "FIXME(eddyb) should use `def_span`." because
it appears to have already been fixed by commit 67727aa7c3.
Move `--sysroot` argument out of the argument file to fix miri issue
Fixes https://github.com/rust-lang/miri/issues/3404.
For now, miri needs this argument to be moved out of the arg file so they can update it if needed.
cc `@RalfJung`
r? `@notriddle`
phase_rustdoc: add a heuristic to make us more certain that this is really rustdoc
Also add anyhow to test-cargo-miri; it has a custom build probe and is widely used so let's make sure the build script does not fail.
