The deprecated `LLVM{Get,Set}ValueName` only work with NUL-terminated
strings, but the `2` variants use explicit lengths, which fits better
with Rust strings and slices. We now use these in new helper functions
`llvm::{get,set}_value_name` that convert to/from `&[u8]`.
Only memoize const fn calls during const eval
Miri and other engines may want to execute the function in order to detect UB inside of them.
r? @RalfJung
Make `process_obligations()` greedier.
`process_obligations()` adds new nodes, but it does not process these
new nodes until the next time it is called.
This commit changes it so that it does process these new nodes within
the same call. This change reduces the number of calls to
`process_obligations()` required to complete processing, sometimes
giving significant speed-ups.
The change required some changes to tests.
- The output of `cycle-cache-err-60010.rs` is slightly different.
- The unit tests required extra cases to handle the earlier processing
of the added nodes. I mostly did these in the simplest possible way,
by making the added nodes be ignored, thus giving outcomes the same as
with the old behaviour. But I changed `success_in_grandchildren()`
more extensively so that some obligations are completed earlier than
they used to be.
r? @nikomatsakis
rustc: split FnAbi's into definitions/direct calls ("of_instance") and indirect calls ("of_fn_ptr").
After this PR:
* `InstanceDef::Virtual` is only used for "direct" virtual calls, and shims around those calls use `InstanceDef::ReifyShim` (i.e. for `<dyn Trait as Trait>::f as fn(_)`)
* this could easily be done for intrinsics as well, to allow their reification, but I didn't do it
* `FnAbi::of_instance` is **always** used for declaring/defining an `fn`, and for direct calls to an `fn`
* this is great for e.g. https://github.com/rust-lang/rust/pull/65881 (`#[track_caller]`), which can introduce the "caller location" argument into "codegen signatures" by only changing `FnAbi::of_instance`, after this PR
* `FnAbi::of_fn_ptr` is used primarily for indirect calls, i.e. to `fn` pointers
* *not* virtual calls (which use `FnAbi::of_instance` with `InstanceDef::Virtual`)
* there's also a couple uses where the `rustc_codegen_llvm` needs to declare (i.e. FFI-import) an LLVM function that has no Rust declaration available at all
* at least one of them could probably be a "weak lang item" instead
As there are many steps, this PR is best reviewed commit by commit - some of which arguably should be in their own PRs, I may have gotten carried away a bit.
cc @nagisa @rkruppe @oli-obk @anp
In most places, we use a span when emitting `expected...found` errors.
However, there were a couple of places where we didn't use any span,
resulting in hard-to-interpret error messages.
This commit attaches the relevant span to these notes, and additionally
switches over to using `note_expected_found` instead of manually
formatting the message
Currently, rustfix has no notion of mutually exclusive suggestions. When
it processes issue-59756, it will attempt to apply two mutually
exclusive suggestions for the same span, causing an error.
Fixes#66910
We have several different kinds of suggestions we can try to make when
type coercion fails. However, we were previously only emitting these
suggestions from `demand_coerce_diag`. This resulted in the compiler
failing to emit applicable suggestions in several different cases, such
as when the implicit return value of a function had the wrong type.
This commit adds a new `emit_coerce_suggestions` method, which tries to
emit a number of related suggestions. This method is called from both
`demand_coerce_diag` and `CoerceMany::coerce_inner`, which covers a much
wider range of cases than before.
We now suggest using `.await` in more cases where it is applicable,
among other improvements.
Update the minimum external LLVM to 7
LLVM 7 is over a year old, which should be plenty for compatibility. The
last LLVM 6 holdout was llvm-emscripten, which went away in #65501.
I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions`,
which was broken by #66522.
