Added an explanation for the E0704 error.
# Description
Adds an explanation on the E0704 error. I tried to stick as closely to the message that the compiler generates. It's the first time I am fixing error messages here, so if there is something I did wrong or should improve, please let me know.
closes#55398
Rollup of 7 pull requests
Successful merges:
- #60287 (Use references for variances_of)
- #60327 (Search for incompatible universes in borrow errors)
- #60330 (Suggest using an inclusive range instead of an exclusive range when the endpoint overflows by 1)
- #60366 (build-gcc: Create missing cc symlink)
- #60369 (Support ZSTs in DispatchFromDyn)
- #60404 (Implement `BorrowMut<str>` for `String`)
- #60417 (Rename hir::ExprKind::Use to ::DropTemps and improve docs.)
Failed merges:
r? @ghost
rustdoc: remove def_ctor hack.
~~No longer necessary since we have `describe_def`.~~
Turns out `def_ctor` was used in conjunction with abusing `tcx.type_of(def_id)` working on both type definitions and `impl`s (specifically, of builtin types), but also reimplementing a lot of the logic that `Clean` already provides on `Ty` / `ty::TraitRef`.
The first commit now does the minimal refactor to keep it working, while the second commit contains the rest of the refactor I started (parts of which I'm not sure we need to keep).
Support ZSTs in DispatchFromDyn
Allows to use ZSTs with 1 byte alignment in `DispatchFromDyn` implementation. This is required for `Box<T, A: Alloc>`
cc #58457
build-gcc: Create missing cc symlink
This PR mostly fixes build error caused by using rustc docker images
to build [rustup][1] (with the error: ``linker `cc` not found``).
I don't know why gcc build script doesn't install cc hard link by default.
In build log, with `make SHELL='sh -x' install`, gcc build script installs c++
hard link but not `cc` one:
```bash
if test "" != "yes" ; then \
rm -f /rustroot/bin/g++; \
/usr/bin/install -c xg++ /rustroot/bin/g++; \
chmod a+x /rustroot/bin/g++; \
rm -f /rustroot/bin/c++; \
( cd /rustroot/bin && \
ln g++ c++ ); \
if [ -f cc1plus ] ; then \
if [ ! -f g++-cross ] ; then \
rm -f /rustroot/bin/x86_64-unknown-linux-gnu-g++; \
( cd /rustroot/bin && \
ln g++ x86_64-unknown-linux-gnu-g++ ); \
rm -f /rustroot/bin/x86_64-unknown-linux-gnu-c++; \
( cd /rustroot/bin && \
ln c++ x86_64-unknown-linux-gnu-c++ ); \
fi ; \
fi; \
fi
```
This might be fixed downstream by manually creating cc hard link
or setting `RUSTFLAGS="-C linker=gcc"` as [suggested by @mati865][2].
But I find it better to fix it upstream in this PR.
[1]: https://github.com/rust-lang/rustup.rs/pull/1815
[2]: https://github.com/rust-lang/rustup.rs/pull/1815#discussion_r279192797
Search for incompatible universes in borrow errors
If we have a borrow that has to live for `'static` we need to check for
any regions in incompatible universes when trying to find the cause.
closes#60274
Debug-print error when using rtunwrap
When I added this macro a while back I didn't have a way to make it print the failure for all types that you might want to unwrap. Now, I came up with a solution.
PGO: Add a run-make test that makes sure that PGO profiling data is used by the compiler during optimizations.
From the tests comment section:
```
# This test makes sure that PGO profiling data leads to cold functions being
# marked as `cold` and hot functions with `inlinehint`.
# The test program contains an `if` were actual execution only ever takes the
# `else` branch. Accordingly, we expect the function that is never called to
# be marked as cold.
```
r? @alexcrichton
Revert "Update Source Code Pro fonts to version 2.030"
Temporary fix for https://github.com/rust-lang/rust/issues/60365https://github.com/rust-lang/rust/pull/60146 updated all fonts (not just the fonts that were buggy), however it looks like the new Source Code Pro is buggy.
We should test this out of tree: `cargo doc` on anything, replace the font in `target/doc`, and use `python -m SimpleHTTPServer` to see what's going on.
Till we figure that out, I'll just back this out.
r? @GuillaumeGomez
This reverts commit 6bafc58ced.
Don't try to render auto-trait bounds with any inference variables
Previously, we checked if the target of a projection type was itself an
inference variable. However, for Rustdoc rendering purposes, there's no
distinction between an inference variable ('_') and a type containing
one (e.g. (MyStruct<u8, _>)) - we don't want to render either of them.
Fixes#60269
Due to the complexity of the original bug, which spans three different
crates (hyper, tower-hyper, and tower), I have been unable to create a
minimized reproduction for the issue.
Cleanup the MIR visitor
* Remove useless `BasicBlock` parameters on methods with `Location`s.
* Prefer `visit_terminator_kind` to `visit_terminator`.
* Remove `Region` from PlaceContexts. `visit_rvalue` should be used when the region is important.
* Remove unused visitor methods.
