[`derivable_impls`]: don't lint if `default()` call expr unsize-coerces to trait object
Fixes#10158.
This fixes a FP where the derive-generated Default impl would have different behavior because of unsize coercion from `Box<T>` to `Box<dyn Trait>`:
```rs
struct S {
x: Box<dyn std::fmt::Debug>
}
impl Default for S {
fn default() -> Self {
Self {
x: Box::<()>::default()
// ^~ Box<()> coerces to Box<dyn Debug>
// #[derive(Default)] would call Box::<dyn Debug>::default()
}
}
}
```
(this intentionally only looks for trait objects `dyn` specifically, and not any unsize coercion, e.g. `&[i32; 5]` to `&[i32]`, because that breaks existing tests and isn't actually problematic, as far as I can tell)
changelog: [`derivable_impls`]: don't lint if `default()` call expression unsize-coerces to trait object
Fix rustdoc-gui tests on Windows
The browser-ui-test update contains fixes needed for backslash handling (they were not correctly escaped).
Since we have a mix of slash and backslash in some tests, I replaced `DOC_FOLDER` variable backslashes with slashes.
And finally it seemed like the unicode escaped wasn't much appreciated on Windows for some reason so I used the character directly.
cc `@klensy`
r? `@notriddle`
Fix explicit-outlives-requirements lint span
Fixes#105150 which caused the span reported by the explicit-outlives-requirements lint to be incorrect when
1) the lint should suggest the entire where clause to be removed and
2) there are inline bounds present that are not inferable outlives requirements
In particular, this would cause rustfix to leave a dangling empty where clause.
Error on unconstrained lifetime in RPITIT
Fixes#109468
The only thing is that I had to split `tests/ui/impl-trait/in-trait/method-signature-matches.rs` into a bunch of different revisions because some error aren't being emitted if all the different examples are all together in one file 🤔
r? `@oli-obk` just because i know you'll review it, feel free to re-roll
Properly check associated consts for infer placeholders
We only reported an error if it was in a "suggestable" position (according to `is_suggestable_infer_ty`) -- this isn't correct for infer tys that can show up in other places in the constant's type, like behind a dyn trait.
fixes#112491
Improve docs/clean up negative overlap functions
Clean up some functions in ways that should not affect behavior, change some names to be clearer (`negative_impl` and `implicit_negative` are not really clear imo), and add some documentation examples.
r? `@spastorino`
Introduce a `Stable` trait to translate MIR to SMIR
This PR introduces a trait `Stable` which defines a type `T` and a `stable()` method to convert the current type to its stable MIR version.
This change is just an implementation detail, and I wanted to get some feedback to whether it would be cleaner than having the `rustc_<type>_to_<type>()` methods for every type we translate to SMIR.
r? `@oli-obk`
r? `@spastorino`
Don't print unsupported split-debuginfo modes with `-Zunstable-options`
Currently unsupported `split-debuginfo` options are enabled by `-Zunstable-options`, for projects that have `-Zunstable-options` for other reasons this can be [an unexpected interaction](https://github.com/rust-lang/rust-clippy/pull/10516#issuecomment-1562604764)
This PR makes it so that `--print split-debuginfo -Zunstable-options` doesn't print unsupported modes, so that a cargo config of e.g.
```toml
[profile.dev]
split-debuginfo = "unpacked"
```
Would not cause an unsupported mode to be enabled on `x86_64-pc-windows-msvc`
loongarch64-none*: Remove environment component from llvm target
A warning is reported when the LLVM triple-implied ABI conflicts with the provided target-abi.
```
warning: triple-implied ABI conflicts with provided target-abi ‘lp64s', using target-abi
```
Specifically, the ABI hint comes from the environment component of the triple. When only the target-abi is provided and no environment, there is no conflict. This PR removes the environment component from the LLVM target name of the `loongarch64-unknown-none-softfloat` target.
Update runtime guarantee for `select_nth_unstable`
#106933 changed the runtime guarantee for `select_nth_unstable` from O(n) to O(n log n), since the old guarantee wasn't actually met by the implementation at the time. Now with #107522, `select_nth_unstable` should be truly linear in runtime, so we can revert its runtime guarantee to O(n). Since #106933 was considered a bug fix, this will probably need an FCP because it counts as a new API guarantee.
r? `@Amanieu`
Stabilize String::leak
Stabilizes the following API:
```Rust
impl String {
pub fn leak(self) -> &'static mut str;
}
```
closes#102929
blocked by having an FCP for stabilization.
Implement `TryFrom<&OsStr>` for `&str`
Recently when trying to work with `&OsStr` I was surprised to find this `impl` missing.
Since the `to_str` method already existed the actual implementation is fairly non-controversial, except for maybe the choice of the error type. I chose an opaque error here instead of something like `std::str::Utf8Error`, since that would already make a number of assumption about the underlying implementation of `OsStr`.
As this is a trait implementation, it is insta-stable, if I'm not mistaken?
Either way this will need an FCP.
I chose "1.64.0" as the version, since this is unlikely to land before the beta cut-off.
`@rustbot` modify labels: +T-libs-api
API Change Proposal: rust-lang/rust#99031 (accepted)
When the `--sysroot` is specified as relative to the current working
directory, the sysroot's rlibs should also be specified as relative
paths. Otherwise, the current working directory ends up in the
absolute paths, and in the linker command line. And the entire linker
command line appears in the PDB file generated by the MSVC linker.
When adding an rlib to the linker command line, if the rlib's canonical
path is in the sysroot's canonical path, then use the current sysroot
path + filename instead of the full absolute path to the rlib. This
means that when `--sysroot=foo` is specified, the linker command line
will contain `foo/rustlib/target/lib/lib*.rlib` instead of the full
absolute path to the same.
This addresses https://github.com/rust-lang/rust/issues/112586
Add support for targets without unwinding in `mir-opt`, and improve `--bless` for it
The main goal of this PR is to add support for targets without unwinding support in the `mir-opt` test suite, by adding the `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment. Similarly to 32bit vs 64bit, when that comment is present, blessed output files will have the `.panic-unwind` or `.panic-abort` suffix, and the right one will be chosen depending on the target's panic strategy.
The `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment replaced all the `ignore-wasm32` comments in the `mir-opt` test suite, as those comments were added due to `wasm32` being a target without unwinding support. The comment was also added on other tests that were only executed on x86 but were still panic strategy dependent.
The `mir-opt` suite was then blessed, which caused a ton of churn as most of the existing output files had to be renamed and (mostly) duplicated with the abort strategy.
---
After [asking on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mir-opt.20tests.20and.20panic.3Dabort), the main concern about this change is it'd make blessing the `mir-opt` suite even harder, as you'd need to both bless it with an unwinding target and an aborting target. This exacerbated the current situation, where you'd need to bless it with a 32bit and a 64bit target already.
Because of that, this PR also makes significant enhancements to `--bless` for the `mir-opt` suite, where it will automatically bless the suite four times with different targets, while requiring minimal cross-compilation.
To handle the 32bit vs 64bit blessing, there is now an hardcoded list of target mapping between 32bit and 64bit. The goal of the list is to find a related target that will *probably* work without requiring additional cross-compilation toolchains on the system. If a mapping is found, bootstrap will bless the suite with both targets, otherwise just with the current target.
To handle the panic strategy blessing (abort vs unwind), I had to resort to what I call "synthetic targets". For each of the target we're blessing (so either the current one, or a 32bit and a 64bit depending on the previous paragraph), bootstrap will extract the JSON spec of the target and change it to include `"panic-strategy": "abort"`. It will then build the standard library with this synthetic target, and bless the `mir-opt` suite with it.
As a result of these changes, blessing the `mir-opt` suite will actually bless it two or four times with different targets, ensuring all possible variants are actually blessed.
---
This PR is best reviewed commit-by-commit.
r? `@jyn514`
cc `@saethlin` `@oli-obk`
