Make CTFE able to check for UB...
... by not doing any optimizations on the `const fn` MIR used in CTFE. This means we duplicate all `const fn`'s MIR now, once for CTFE, once for runtime. This PR is for checking the perf effect, so we have some data when talking about https://github.com/rust-lang/const-eval/blob/master/rfcs/0000-const-ub.md
To do this, we now have two queries for obtaining mir: `optimized_mir` and `mir_for_ctfe`. It is now illegal to invoke `optimized_mir` to obtain the MIR of a const/static item's initializer, an array length, an inline const expression or an enum discriminant initializer. For `const fn`, both `optimized_mir` and `mir_for_ctfe` work, the former returning the MIR that LLVM should use if the function is called at runtime. Similarly it is illegal to invoke `mir_for_ctfe` on regular functions.
This is all checked via appropriate assertions and I don't think it is easy to get wrong, as there should be no `mir_for_ctfe` calls outside the const evaluator or metadata encoding. Almost all rustc devs should keep using `optimized_mir` (or `instance_mir` for that matter).
Enhance type inference errors involving the `?` operator
This patch adds a special-cased note on type inference errors when the error span points to a `?` return. It also makes the primary label for such errors "cannot infer type of `?` error" in cases where before we would have only said "cannot infer type".
One beneficiary of this change is async blocks, where we can't explicitly annotate the return type and so may not generate any other help (#77880); this lets us at least print the error type we're converting from and anything we know about the type we can't fully infer. More generally, it signposts that an implicit conversion is happening that may have impeded type inference the user was expecting. We already do something similar for [mismatched type errors](2987785df3/src/test/ui/try-block/try-block-bad-type.stderr (L7)).
The check for a relevant `?` operator is built into the existing HIR traversal which looks for places that could be annotated to resolve the error. That means we could identify `?` uses anywhere in the function that output the type we can't infer, but this patch just sticks to adding the note if the primary span given for the error has the operator; if there are other expressions where the type occurs and one of them is selected for the error instead, it's more likely that the `?` operator's implicit conversion isn't the sole cause of the inference failure and that adding an additional diagnostic would just be noise. I added a ui test for one such case.
The data about the `?` conversion is passed around in a `UseDiagnostic` enum that in theory could be used to add more of this kind of note in the future. It was also just easier to pass around than something with a more specific name. There are some follow-up refactoring commits for the code that generates the error label, which was already pretty involved and made a bit more complicated by this change.
Replace tabs earlier in diagnostics
This replaces tabs earlier in the diagnostics emitting process, which allows various margin calculations to ignore the existence of tabs. It does add a string copy for the source lines that are emitted.
Fixes https://github.com/rust-lang/rust/issues/78438
r? `@estebank`
Suggest async {} for async || {}
Fixes#76011
This adds support for adding help diagnostics to the feature gating checks and
then uses it for the async_closure gate to add the extra bit of help
information as described in the issue.
rustdoc: Resolve `&str` as `str`
People almost always are referring to `&str`, not `str`, so this will
save a manual link resolve in many cases.
Note that we already accept `&` (resolves to `reference`) in intra-doc
links, so this shouldn't cause breakage.
r? `@jyn514`
Explain method-call move errors in loops
PR #73708 added a more detailed explanation of move errors that occur
due to a call to a method that takes `self`. This PR extends that logic
to work when a move error occurs due to a method call in the previous
iteration of a loop.
rustdoc: Remove `*` intra-doc alias for `pointer`
It's not valid Rust code and it can easily be confused with a wildcard
glob pattern or something else. People can always use `pointer` instead,
so it's just removing an alias.
It hasn't hit stable yet (I think it's still on nightly), so it's okay
to remove it. (We can always add it back later if we change our mind
too.)
r? `@jyn514`
cc https://github.com/rust-lang/rust/pull/80885#discussion_r554622737
Use standard formatting for "rust-call" ABI message
Nearly all error messages start with a lowercase letter and don't use
articles - instead they refer to the plural case.
It's not valid Rust code and it can easily be confused with a wildcard
glob pattern or something else. People can always use `pointer` instead,
so it's just removing an alias.
It hasn't hit stable yet (I think it's still on nightly), so it's okay
to remove it. (We can always add it back later if we change our mind
too.)
People almost always are referring to `&str`, not `str`, so this will
save a manual link resolve in many cases.
Note that we already accept `&` (resolves to `reference`) in intra-doc
links, so this shouldn't cause breakage.
Remove under-used ImplPolarity enum
It doesn't make much sense to have an enum with only two possible values and to store it inside an `Option` in my opinion when you can do all the same with a simple boolean. I don't expect any chances, performance or RSS usage wise.
r? ``@jyn514``
Support `download-ci-llvm` on NixOS
In particular, the CI built `libLLVM-*.so` needs to have `libz.so`
RPATHed so that binaries like `llvm-config` work at all.
Use correct span for structured suggestion
On structured suggestion for `let` -> `const` and `const` -> `let`, use
a proper `Span` and update tests to check the correct application.
Follow up to #80012.
Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path
Fixes#74355
- ~~waiting on author + draft PR since my code ought to be cleaned up _w.r.t._ the way I avoid the `.unwrap()`s:~~
- ~~dummy items may avoid the first `?`,~~
- ~~but within the module traversal some tests did fail (hence the second `?`), meaning the crate did not possess the exact path of the containing module (`extern` / `impl` blocks maybe? I'll look into that).~~
r? `@jyn514`
Fix x.py install not working with relative prefix
The code powering `./x.py install` did not handle relative paths well: the installation script is executed inside a temporary directory, so all the relative paths specified in `config.toml` and in the `DESTDIR` environment variable were relative to that temporary directory. The original code fixed the problem for `config.toml` paths by canonicalizing the prefix, but breaking `DESTDIR`. https://github.com/rust-lang/rust/pull/80240 fixed the `DESTDIR` problem, but also regressed `config.toml` paths (#80683).
This PR refactors the installation code to generate paths that *in my understanding* are correct, adding comments in the meantime to explain what each step does. There was no documentation on why choices were made before, so my understanding could actually be wrong.
Regardless, executed `./x.py install` with various combinations of `config.toml` and `DESTDIR` paths, and everything seems to work according to my understanding. Still, I'd love if `@vext01` and `@yshui` could test these changes.
r? `@Mark-Simulacrum`
`@rustbot` modify labels: beta-nominated T-infra
PR #73708 added a more detailed explanation of move errors that occur
due to a call to a method that takes `self`. This PR extends that logic
to work when a move error occurs due to a method call in the previous
iteration of a loop.
This adjusts the `rustdoc` trait impl collection path to preserve `Deref` impls
from other crates. This adds a first pass to map all of the `Deref` type to
target edges and then recursively preserves all targets.
