diff options
| author | bors <bors@rust-lang.org> | 2024-07-04 23:45:56 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-07-04 23:45:56 +0000 |
| commit | 489233170abcc97f59a1ee2211535f0ff67a0b43 (patch) | |
| tree | 6c0aa43dade23cab3ff64c61f5d960ec78a403d1 /compiler/rustc_mir_transform/src/coverage | |
| parent | cc8da78a036dc3c15c35a97651b02af9a6d30c1e (diff) | |
| parent | 41b98da42d0500e38b9dd85c82110ba177ac4de1 (diff) | |
| download | rust-489233170abcc97f59a1ee2211535f0ff67a0b43.tar.gz rust-489233170abcc97f59a1ee2211535f0ff67a0b43.zip | |
Auto merge of #123781 - RalfJung:miri-fn-identity, r=oli-obk
Miri function identity hack: account for possible inlining Having a non-lifetime generic is not the only reason a function can be duplicated. Another possibility is that the function may be eligible for cross-crate inlining. So also take into account the inlining attribute in this Miri hack for function pointer identity. That said, `cross_crate_inlinable` will still sometimes return true even for `inline(never)` functions: - when they are `DefKind::Ctor(..) | DefKind::Closure` -- I assume those cannot be `InlineAttr::Never` anyway? - when `cross_crate_inline_threshold == InliningThreshold::Always` so maybe this is still not quite the right criterion to use for function pointer identity.
Diffstat (limited to 'compiler/rustc_mir_transform/src/coverage')
0 files changed, 0 insertions, 0 deletions
