Rollup of 9 pull requests
Successful merges:
- #103035 (Even nicer errors from assert_unsafe_precondition)
- #103106 (Try to say that memory outside the AM is always exposed)
- #103475 (Make param index generation a bit more robust)
- #103525 (Move a wf-check into the site where the value is instantiated)
- #103564 (library: allow some unused things in Miri)
- #103586 (Process registered region obligation in `resolve_regions_with_wf_tys`)
- #103592 (rustdoc: remove redundant CSS selector `.notable-traits .notable`)
- #103593 (Remove an unused parser function (`Expr::returns`))
- #103611 (Add test for issue 103574)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `commit_if_ok` probe from NLL type relation
It was not really necessary to add the `commit_if_ok` in #100092 -- I added it to protect us against weird inference error messages due to recursive RPIT calls, but we are always on the error path when this happens anyways, and I can't come up with an example that makes this manifest.
Fixes#103599
r? `@oli-obk` since you reviewed #100092, feel free to re-roll.
🅱️📢 beta-nominating this since it's on beta (which forks in ~a week~ two days 😨) -- worst case we could revert the original PR on beta and land this on nightly, to give it some extra soak time...
Diagnostic derives: allow specifying multiple alternative suggestions
This allows porting `span_suggestions()` to diagnostic structs.
Doesn't work for `multipart_suggestions()` because the rank would be reversed - the struct would specify multiple spans, each of which has multiple possible replacements, while `multipart_suggestions()` creates multiple possible replacements, each with multiple spans.
suggest type annotation for local statement initialed by ref expression
In a local statement with a type declaration, if a ref expression is used on the right side and not used on the left side, in addition to removing the `&` and `&mut` on the right side, we can add them on the left side alternatively
Fixes#102892
Add eval hack in `super_relate_consts` back
Partially reverts 01adb7e98d.
This extra eval call *still* needs to happen, for example, in `normalize_param_env_or_error` when a param-env predicate has an unnormalized constant, since the param-env candidates never get normalized during candidate assembly (everywhere else we can assume that they are normalized fully).
r? `@lcnr,` though I feel like I've assigned quite a few PRs to you in the last few days, so feel free to reassign to someone else familiar with this code if you're busy!
cc #103243 (fixes the issue, but don't want to auto-close that until a backport is performed).
Assert if inference vars are leaking from `InferCtxt::fully_resolve`
`InferCtxt::fully_resolve` shouldn't return unresolved inference vars without us at least being aware of it, so make it an assertion now. This should only happen in cases where we used to be returning `ReEmpty`...
cc `@jackh726`
Split phase change from `MirPass`
The main goal here is to simplify the pass manager logic. `MirPass` no longer contains the `phase_change` method, and `run_passes` instead accepts an `Option<PhaseChange>`. The hope is that this addresses the comments (and maybe perf regression) from #99102 .
r? `@oli-obk` cc `@RalfJung`
rustc: Use `unix_sigpipe` instead of `rustc_driver::set_sigpipe_handler`
This is the first (known) step towards starting to use `unix_sigpipe` in the wild. Eventually, `rustc_driver::set_sigpipe_handler` can be removed and all clients can use `unix_sigpipe` instead.
For now we just start using `unix_sigpipe` in one place: `rustc` itself.
It is easy to manually verify this change. If you remove `#[unix_sigpipe = "sig_dfl"]` and run `./x.py build` you will get an ICE when you do `./build/x86_64-unknown-linux-gnu/stage1/bin/rustc --help | false`. Add back `#[unix_sigpipe = "sig_dfl"]` and the ICE disappears again.
PR that added `set_sigpipe_handler`: https://github.com/rust-lang/rust/pull/49606
Tracking issue for `unix_sigpipe`: #97889
Not sure exactly how to label this PR. Going with T-libs for now since this is a T-libs feature.
````@rustdoc```` labels +T-libs
Support raw-dylib functions being used inside inlined functions
Fixes#102714
Issue Details:
When generating the import library for `raw-dylib` symbols, we currently only use the functions and variables declared within the current crate. This works fine if all crates are static libraries or `rlib`s as the generated import library will be contained in the static library or `rlib` itself, but if a dependency is a dynamic library AND the use of a `raw-dylib` function or variable is inlined or part of a generic instantiation then the current crate won't see its dependency's import library and so linking will fail.
Fix Details:
Instead, when we generate the import library for a `dylib` or `bin` crate, we will now generate it for the symbols both for the current crate and all upstream crates. We do this in two steps so that the import library for the current crate is passed into the linker first, thus it is preferred if there are any ambiguous symbols.
`TerminatorCodegenHelper` has three methods `llblock`, `llbb`, and
`lltarget`. They're all similar, but the names given no indication of
the differences.
This commit renames `lltarget` as `llbb_with_landing_pad`, and `llblock`
as `llbb_with_cleanup`. These aren't fantastic names, but at least it's
now clear that `llbb` is the lowest-level of the three and the other two
wrap it.
Ensure:
- builders always have a `bx` suffix;
- backend basic blocks always have an `llbb` suffix,
- paired builders and basic blocks have consistent prefixes.
