Argument type error improvements
Motivated by this interesting code snippet:
```rust
#[derive(Copy, Clone)]
struct Wrapper<T>(T);
fn foo(_: fn(i32), _: Wrapper<i32>) {}
fn f(_: u32) {}
fn main() {
let w = Wrapper::<isize>(1isize);
foo(f, w);
}
```
Which currently errors like:
```
error[E0308]: arguments to this function are incorrect
--> src/main.rs:10:5
|
10 | foo(f, w);
| ^^^ - - expected `i32`, found `isize`
| |
| expected `i32`, found `u32`
|
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> src/main.rs:4:4
|
4 | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
```
Specifically, that double `expected .. found ..` which is very difficult to correlate to the types in the arguments. Also, the fact that "expected `i32`, found `isize`" and the other argument mismatch label don't even really explain what's going on here.
After this PR:
```
error[E0308]: arguments to this function are incorrect
--> $DIR/two-mismatch-notes.rs:10:5
|
LL | foo(f, w);
| ^^^
|
note: expected fn pointer, found fn item
--> $DIR/two-mismatch-notes.rs:10:9
|
LL | foo(f, w);
| ^
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
note: expected struct `Wrapper`, found a different struct `Wrapper`
--> $DIR/two-mismatch-notes.rs:10:12
|
LL | foo(f, w);
| ^
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> $DIR/two-mismatch-notes.rs:4:4
|
LL | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
```
Yeah, it's a bit verbose, but much clearer IMO.
---
Open to discussions about how this could be further improved. Motivated by `@jyn514's` [tweet](https://mobile.twitter.com/joshuayn514/status/1558042020601634816) here.
wf: correctly `shallow_resolve` consts
`shallow_resolve` on `InferConst` is always a noop. this is mostly irrelevant as inference vars should already be resolved at most - if not all - call sites. Haven't actually looked too deeply into whether this was a problem.
Erase regions better in `promote_candidate`
Use `tcx.erase_regions` instead of manually walking through the substs.... this also makes the code slightly simpler 🙈Fixes#100360Fixes#89851
Rollup of 9 pull requests
Successful merges:
- #100022 (Optimize thread ID generation)
- #100030 (cleanup code w/ pointers in std a little)
- #100229 (add -Zextra-const-ub-checks to enable more UB checking in const-eval)
- #100247 (Generalize trait object generic param check to aliases.)
- #100255 (Adding more verbose documentation for `std::fmt::Write`)
- #100366 (errors: don't fail on broken primary translations)
- #100396 (Suggest const and static for global variable)
- #100409 (rustdoc: don't generate DOM element for operator)
- #100443 (Add two let else regression tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
errors: don't fail on broken primary translations
If a primary bundle doesn't contain a message then the fallback bundle is used. However, if the primary bundle's message is broken (e.g. it refers to a interpolated variable that the compiler isn't providing) then this would just result in a compiler panic. While there aren't any primary bundles right now, this is the type of issue that could come up once translation is further along.
r? ```@compiler-errors``` (since this comes out of a in-person discussion we had at RustConf)
Generalize trait object generic param check to aliases.
The current algorithm only checks that `Self` does not appear in defaults for traits. This is not sufficient for trait aliases.
This PR moves the check to trait object elaboration, which sees through trait aliases.
Fixes https://github.com/rust-lang/rust/issues/82927.
Fixes https://github.com/rust-lang/rust/issues/84789.
passes: load `defined_lib_features` query less
Hopefully addresses the perf regressions from #99212 (see #99905).
Re-structure the stability checks for library features to avoid calling `defined_lib_features` for any more crates than necessary for each of the implications or local feature attributes that need validation.
r? `@ghost` (just checking perf at first)
Update to LLVM 15
For preliminary testing. Some LLVM 15 compatibility fixes were applied separately in #99512.
Release timeline:
* LLVM 15 branched on Jul 26.
* The final LLVM 15.0.0 release is scheduled for Sep 6.
* Current nightly (1.65.0) is scheduled for Nov 3.
Changes in this PR (apart from the LLVM update):
* Pass `--set llvm.allow-old-toolchain` for many Docker images. LLVM 16 will require GCC >= 7.1, while LLVM 15 still allows older compilers with an option. Specify the option for builders still using GCC 5.4. #95026 updated some of the used toolchains, but not all.
* Use the `+atomics-32` target feature for thumbv6m.
* Explicitly link libatomic when cross-compiling LLVM to 32-bit target.
* Explicitly disable zstd support, to avoid libzstd.so dependency.
New LLVM patches ([commits](https://github.com/rust-lang/llvm-project/commits/rustc/15.0-2022-08-09)):
* [rust-only] Fix ICE with GCC 5.4 (15be58d7f0)
* [rust-only] Fix build with GCC 5.4 (774edc10fa)
* ~~[rust-only] Fix build with GCC 5.2 (1a6069a7bb)~~
* ~~[rust-only] Fix ICE with GCC 5.2 (493081f290)~~
* ~~[rust-only] Fix build with GCC 5.2 (0fc5979d73)~~
* [backported] Addition of `+atomics` target feature (57bdd9892d).
* [backported] Revert compiler-rt change that broke powerpc (9c68b43915)
* [awaiting backport] Fix RelLookupTableConverter on gnux32 (639388a05f / https://github.com/llvm/llvm-project/issues/57021)
Tested images: dist-x86_64-linux, armhf-gnu, arm-android, dist-s390x-linux, dist-x86_64-illumos, dist-x86_64-freebsd, wasm32, dist-x86_64-musl, dist-various-1, dist-riscv64-linux, dist-mips-linux, dist-mipsel-linux, dist-powerpc-linux, dist-aarch64-linux, dist-x86_64-apple, x86_64-msvc-1, x86_64-msvc-2, dist-various-2, dist-arm-linux
Tested up to the usual ipv6 error: test-various, i686-gnu, x86_64-gnu-nopt
r? `@ghost`
Stringify non-shorthand visibility correctly
This makes `stringify!(pub(in crate))` evaluate to `pub(in crate)` rather than `pub(crate)`, matching the behavior before the `crate` shorthand was removed. Further, this changes `stringify!(pub(in super))` to evaluate to `pub(in super)` rather than the current `pub(super)`. If the latter is not desired (it is _technically_ breaking), it can be undone.
Fixes#99981
`@rustbot` label +C-bug +regression-from-stable-to-beta +T-compiler
Fix flags when using clang as linker for Fuchsia
Don't add C runtime or set dynamic linker when linking with clang for
Fuchsia. Clang already does this for us.
Use `&mut Diagnostic` instead of `&mut DiagnosticBuilder` unless needed
This seems to be the established convention (02ff9e0) when `DiagnosticBuilder` was first added. I am guilty of introducing some of these.
Remove duplicated temporaries creating during box derefs elaboration
Temporaries created with `MirPatch::new_temp` will be declared after
patch application. Remove manually created duplicate declarations.
Removing duplicates exposes another issue. Visitor elaborates
terminator twice and attempts to access new, but not yet available,
local declarations. Remove duplicated call to `visit_terminator`.
Extracted from #99946.
Determine match_has_guard from candidates instead of looking up thir table again
Currently looking through mir build of matches because of interest in deref patterns. Finding some micro-optimizable things.
Check if enum from foreign crate has any non exhaustive variants when attempting a cast
Fixes#91161
As stated in the issue, this will require a crater run as it might break other people's stuff.
Keep going if normalized projection has unevaluated consts in `QueryNormalizer`
#100312 was the wrong approach, I think this is the right one.
When normalizing a type, if we see that it's a projection, we currently defer to `tcx.normalize_projection_ty`, which normalizes the projections away but doesn't touch the unevaluated constants. So now we just continue to fold the type if it has unevaluated constants so we make sure to evaluate those too, if we can.
Fixes#100217Fixes#83972Fixes#84669Fixes#86710Fixes#82268Fixes#73298
