Rollup of 6 pull requests
Successful merges:
- #109806 (Workaround #109797 on windows-gnu)
- #109957 (diagnostics: account for self type when looking for source of unsolved type variable)
- #109960 (Fix buffer overrun in bootstrap and (test-only) symlink_junction)
- #110013 (Label `non_exhaustive` attribute on privacy errors from non-local items)
- #110016 (Run collapsed GUI test in mobile mode as well)
- #110022 (fix: fix regression in #109203)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Label `non_exhaustive` attribute on privacy errors from non-local items
Label when an ADT is `non_exhaustive` and we get a privacy error, help with confusion in a case like this:
```rust
#[non_exhaustive]
pub struct Foo;
// other crate
let x = Foo;
//~^ ERROR unit struct `Foo` is private
```
Fix buffer overrun in bootstrap and (test-only) symlink_junction
I don't think these can be hit in practice, due to their inputs being valid paths. It's also not security-sensitive code, but just... bad vibes.
I think this is still not really the right way to do this (in terms of path correctness), but is no worse than it was.
r? `@ChrisDenton`
diagnostics: account for self type when looking for source of unsolved type variable
Fixes#109905.
When searching for the source of an unsolved infer var inside of a list of generic args, we look through the `tcx.generics_of(…).own_substs(…)` which *skips* the self type if present. However, the computed `argument_index` is later[^1] used to index into `tcx.generics_of(…).params` which may still contain the self type. In such case, we are off by one when indexing into the parameters.
From now on, we account for this immediately after calling `own_substs` which keeps things local.
This also fixes the wrong output in the preexisting UI test `inference/need_type_info/concrete-impl.rs` which was overlooked. It used to claim that the *type of type parameter `Self`* couldn't be inferred in `<Struct as Ambiguous<_>>::method()` which of course isn't true: `Self` equals `Struct` here, `A` couldn't be inferred.
`@rustbot` label A-diagnostics
[^1]: f98a271814/compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs (L471)
extend `detect_src_and_out` test
> I was thinking about the following cases when I wrote the comment in #109055
>
> 1. Running bootstrap from the source root.
> 2. Running from a subdirectory of the source root.
> 3. Running from outside the source root.
> 4. Running on a different machine from where bootstrap was compiled (which will be important > for #107812). You can mostly replicate this by renaming the source root so it no longer exists on disk.
> 5. Running with `--build-dir`.
> 6. Running with `$RUST_BOOTSTRAP_CONFIG` set in the environment and `build-dir` set in the file.
Tested all the topics mentioned above. All worked fine. The test is now also covers if build dir is manually specified in config.
r? `@jyn514`
helps #109120 partially
Rollup of 7 pull requests
Successful merges:
- #109395 (Fix issue when there are multiple candidates for edit_distance_with_substrings)
- #109755 (Implement support for `GeneratorWitnessMIR` in new solver)
- #109782 (Don't leave a comma at the start of argument list when removing arguments)
- #109977 (rustdoc: avoid including line numbers in Google SERP snippets)
- #109980 (Derive String's PartialEq implementation)
- #109984 (Remove f32 & f64 from MemDecoder/MemEncoder)
- #110004 (add `dont_check_failure_status` option in the compiler test)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove f32 & f64 from MemDecoder/MemEncoder
r? ```@Nilstrieb```
since they said (maybe joked) on discord that it's a bug if the compiler uses f32 anywhere 🙃
Implement support for `GeneratorWitnessMIR` in new solver
r? ```@cjgillot```
I mostly want this to cut down the number of failing UI tests when running the UI test suite with `--compare-mode=next-solver`, but there doesn't seem like much reason to block implementing this since it adds minimal complexity to the existing structural traits impl in the new solver.
If others are against adding this for some reason, then maybe we should just make `GeneratorWitnessMIR` return `NoSolution` for these traits. Anything but an ICE please 😸🧊
Check pattern refutability on THIR
The current `check_match` query is based on HIR, but partially re-lowers HIR into THIR.
This PR proposed to use the results of the `thir_body` query to check matches, instead of re-building THIR.
Most of the diagnostic changes are spans getting shorter, or commas/semicolons not getting removed.
This PR degrades the diagnostic for confusing constants in patterns (`let A = foo()` where `A` resolves to a `const A` somewhere): it does not point ot the definition of `const A` any more.
Update to LLVM 16.0.1
Update to current `release/16.x` branch. I've opted for a rebase to get rid of all our custom cherry-picks.
Fixes#109775.
r? `@cuviper`
Rollup of 7 pull requests
Successful merges:
- #109909 (Deny `use`ing tool paths)
- #109921 (Don't ICE when encountering `dyn*` in statics or consts)
- #109922 (Disable `has_thread_local` on OpenHarmony)
- #109926 (write threads info into log only when debugging)
- #109968 (Add regression test for #80409)
- #109969 (Add regression test for #86351)
- #109973 (rustdoc: Improve logo display very small screen)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
write threads info into log only when debugging
The current tracing log will unconditionally write thread information during parallel compilation, which sometimes confuses some normal output log information
This fixes the UI test failure of:
```
[ui] tests/ui/consts/const_in_pattern/issue-73431.rs
```
Updates #75760
Disable `has_thread_local` on OpenHarmony
OpenHarmony uses emulated TLS, which doesn't link properly when using thread-local variables across crate boundaries with `-C prefer-dynamic`. This PR makes thread_local! use pthreads directly instead.
Don't ICE when encountering `dyn*` in statics or consts
Since we have properly implemented `dyn*` support in CTFE (#107728), let's not ICE here anymore.
Fixes#105777
r? `@eholk`
