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`
update Miri
I had to use a hacked version of josh to create this, so let's be careful with merging this and maybe wait a bit to see if the josh issue becomes more clear. But the history looks good to me, we are not adding duplicates of rustc commits that were previously mirrored to Miri.
Also I want to add some cross-testing of Miri in x.py.
Truncate thread names on Linux and Apple targets
These targets have system limits on the thread names, 16 and 64 bytes
respectively, and `pthread_setname_np` returns an error if the name is
longer. However, we're not in a context that can propagate errors when
we call this, and we used to implicitly truncate on Linux with `prctl`,
so now we manually truncate these names ahead of time.
r? ``````@thomcc``````
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.
rustdoc: Use `unix_sigpipe` instead of `rustc_driver::set_sigpipe_handler`
Do what was already done for `rustc` in #102587, namely start using `unix_sigpipe` instead of `rustc_driver::set_sigpipe_handler`.
After this has been merged, we can completely remove `rustc_driver::set_sigpipe_handler`.
PR that added `set_sigpipe_handler`: https://github.com/rust-lang/rust/pull/49606
Tracking issue for `unix_sigpipe`: #97889
Verification of this change
---------------------------
1. Remove `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE
1. Add back `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE fixed
``@rustbot`` labels +T-rustdoc
rustdoc: remove redundant CSS `a.test-arrow:hover`
In 4b402dbe69, when this rule was added, it was overriding a rule that made all links in docblock get an underline when hovered. This became redundant when, after reordering the rules, 7585632052 changed the pro-underline rule to exclude the test-arrow link anyway.
Delay span bug when we can't map lifetimes back in `collect_trait_impl_trait_tys`
When a lifetime is late-bound in a trait signature, but early-bound in an impl signature, we already emit an error -- however, we also ICE in `collect_trait_impl_trait_tys`, so just delay a bug here.
Fixes#103407
Don't ICE when reporting borrowck errors involving regions from `anonymous_lifetime_in_impl_trait`
The issue here is that when we have:
```
trait Trait<'a> { .. }
fn foo(arg: impl Trait) { .. }
```
The anonymous lifetime `'_` that we generate for `arg: impl Trait` doesn't end up in the argument type (which is a param) but in a where-clause of the function, in a predicate whose self type is that param ty.
Fixes#101660
r? ``@cjgillot``
Start using `unix_sigpipe` instead of
`rustc_driver::set_sigpipe_handler`.
After this has been merged, we can completely remove
`rustc_driver::set_sigpipe_handler`.
Verification of this change
---------------------------
1. Remove `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE
1. Add back `#[unix_sigpipe = "sig_dfl"]`
1. Run `./x.py build`
1. Run `./build/aarch64-apple-darwin/stage1/bin/rustdoc --help | false`
1. Observe ICE fixed
In 4b402dbe69, when this rule was added, it
was overriding a rule that made all links in docblock get an underline when
hovered. This became redundant when, after reordering the rules,
7585632052 changed the pro-underline rule to
exclude the test-arrow link anyway.
Only apply `ProceduralMasquerade` hack to older versions of `rental`
The latest version of `rental` (v0.5.6) contains a fix that allows it to
compile without relying on the pretty-print back-compat hack.
Hopefully, there are no longer any crates relying on the affected
versions of the (much less popular) `procedural-masquerade` crate. This
should allow us to target the pretty-print back-compat hack specifically
to older versions of `rental`, and specifically mention upgrading to
`rental` v0.5.6 in the lint message.
Rollup of 7 pull requests
Successful merges:
- #99578 (Remove redundant lifetime bound from `impl Borrow for Cow`)
- #99939 (Sort tests at compile time, not at startup)
- #102271 (Stabilize `duration_checked_float`)
- #102766 (Don't link to `libresolv` in libstd on Darwin)
- #103277 (Update libstd's libc to 0.2.135 (to make `libstd` no longer pull in `libiconv.dylib` on Darwin))
- #103437 (Sync rustc_codegen_cranelift)
- #103466 (Fix grammar in docs for std::io::Read)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix grammar in docs for std::io::Read
Two independent clauses were incorrectly joined by a bare comma. The simplest fix would be to switch to a semicolon, but I think it's slightly better to keep the comma and use the coordinating conjunction "so".
Update libstd's libc to 0.2.135 (to make `libstd` no longer pull in `libiconv.dylib` on Darwin)
This is to pull in https://github.com/rust-lang/libc/pull/2944.
It's related to https://github.com/rust-lang/rust/pull/102766, in that they both remove unused dylibs from libstd on Darwin platforms. As a result, I'm marking this as relnotes since everybody agreed it was good to add it to the other as well. (The note should be about no longer linking against libiconv -- the libc update is irrelevant).
Might as well have the same reviewer too.
r? `@Mark-Simulacrum`
Don't link to `libresolv` in libstd on Darwin
Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of https://github.com/rust-lang/rust/pull/44965). I had thought we needed this for `getaddrinfo` or something, but we do not / cannot safely use it.
I'd like to fix this for `libiconv` too (the other library we pull in. that's harder since it's coming in through `libc`, which is https://github.com/rust-lang/libc/pull/2944)).
---
This may warrant release notes. I'm not sure but I've added the flag regardless -- It's a change to the list of dylibs every Rust program pulls in, so it's worth mentioning.
It's pretty unlikely anybody was relying on this being pulled in, and `std` does not guarantee that it will link (and thus transitively provide access to) any particular system library -- anybody relying on that behavior would already be broken when dynamically linking std. That is, there's an outside chance something will fail to link on macOS and iOS because it was accidentally relying on our unnecessary dependency.
(If that *does* happen, that project could be easily fixed by linking libresolv explicitly on those platforms, probably via `#[link(name = "resolv")] extern {}`,` -Crustc-link-lib=resolv`, `println!("cargo:rustc-link-lib=resolv")`, or one of several places in `.config/cargo.toml`)
---
I'm also going to preemptively add the nomination for discussing this in the libs meeting. Basically: Do we care about programs that assume we will bring libraries in that we do not use. `libresolv` and `libiconv` on macOS/iOS are in this camp (`libresolv` because we used to use it, and `libiconv` because the `libc` crate was unintentionally(?) pulling it in to every Rust program).
I'd like to remove them both, but this may cause link issues programs that are relying on `std` to depend on them transitively. (Relying on std for this does not work in all build configurations, so this seems very fragile, and like a use case we should not support).
More generally, IMO we should not guarantee the specific set of system-provided libraries we use (beyond what is implied by an OS version requirement), which means we'd be free to remove this cruft.
Stabilize `duration_checked_float`
## Stabilization Report
This stabilization report is for a stabilization of `duration_checked_float`, tracking issue: https://github.com/rust-lang/rust/issues/83400.
### Implementation History
- https://github.com/rust-lang/rust/pull/82179
- https://github.com/rust-lang/rust/pull/90247
- https://github.com/rust-lang/rust/pull/96051
- Changed error type to `FromFloatSecsError` in https://github.com/rust-lang/rust/pull/90247
- https://github.com/rust-lang/rust/pull/96051 changes the rounding mode to round-to-nearest instead of truncate.
## API Summary
This stabilization report proposes the following API to be stabilized in `core`, along with their re-exports in `std`:
```rust
// core::time
impl Duration {
pub const fn try_from_secs_f32(secs: f32) -> Result<Duration, TryFromFloatSecsError>;
pub const fn try_from_secs_f64(secs: f64) -> Result<Duration, TryFromFloatSecsError>;
}
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct TryFromFloatSecsError { ... }
impl core::fmt::Display for TryFromFloatSecsError { ... }
impl core::error::Error for TryFromFloatSecsError { ... }
```
These functions are made const unstable under `duration_consts_float`, tracking issue #72440.
There is an open question in the tracking issue around what the error type should be called which I was hoping to resolve in the context of an FCP.
In this stabilization PR, I have altered the name of the error type to `TryFromFloatSecsError`. In my opinion, the error type shares the name of the method (adjusted to accommodate both types of floats), which is consistent with other error types in `core`, `alloc` and `std` like `TryReserveError` and `TryFromIntError`.
## Experience Report
Code such as this is ready to be converted to a checked API to ensure it is panic free:
```rust
impl Time {
pub fn checked_add_f64(&self, seconds: f64) -> Result<Self, TimeError> {
// Fail safely during `f64` conversion to duration
if seconds.is_nan() || seconds.is_infinite() {
return Err(TzOutOfRangeError::new().into());
}
if seconds.is_sign_positive() {
self.checked_add(Duration::from_secs_f64(seconds))
} else {
self.checked_sub(Duration::from_secs_f64(-seconds))
}
}
}
```
See: https://github.com/artichoke/artichoke/issues/2194.
`@rustbot` label +T-libs-api -T-libs
cc `@mbartlett21`
