Using deref target instead of pointer itself avoids providing access to
`&Rc<T>` for malicious implementations, which would allow calling
`Rc::get_mut`.
This is a breaking change necessary due to unsoundness, however
the impact of it should be minimal.
This only fixes the issue with malicious `PartialEq` implementations,
other `Pin` soundness issues are still here.
See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311/73>
for more details.
Use Module::print() instead of a PrintModulePass
llvm::Module has a print() method. It is unnecessary to create a pass just for the purpose of printing LLVM IR.
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
