diff options
| author | Matthew Maurer <mmaurer@google.com> | 2024-03-25 19:27:43 +0000 |
|---|---|---|
| committer | Matthew Maurer <mmaurer@google.com> | 2024-04-02 19:11:16 +0000 |
| commit | 6aa89f684e4427a9d08e35b572f9071705105140 (patch) | |
| tree | 205064196db2851129cda806a8179f67db1c934d /compiler/rustc_codegen_llvm/src/errors.rs | |
| parent | 93c2bace58b36ba297f06505b55aef5b8eba954f (diff) | |
| download | rust-6aa89f684e4427a9d08e35b572f9071705105140.tar.gz rust-6aa89f684e4427a9d08e35b572f9071705105140.zip | |
Track reason for creating a `ReifyShim`
KCFI needs to be able to tell which kind of `ReifyShim` it is examining in order to decide whether to use a concrete type (`FnPtr` case) or an abstract case (`Vtable` case). You can *almost* tell this from context, but there is one case where you can't - if a trait has a method which is *not* `#[track_caller]`, with an impl that *is* `#[track_caller]`, both the vtable and a function pointer created from that method will be `ReifyShim(def_id)`. Currently, the reason is optional to ensure no additional unique `ReifyShim`s are added without KCFI on. However, the case in which an extra `ReifyShim` is created is sufficiently rare that this may be worth revisiting to reduce complexity.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src/errors.rs')
0 files changed, 0 insertions, 0 deletions