about summary refs log tree commit diff
path: root/tests/codegen/patchable-function-entry/patchable-function-entry-no-flag.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2024-07-04 23:45:56 +0000
committerbors <bors@rust-lang.org>2024-07-04 23:45:56 +0000
commit8620e85a1ce15e213b30db3f130f7360f4c7396d (patch)
tree6fca0383c753517ff735e83c5292f814ce03b594 /tests/codegen/patchable-function-entry/patchable-function-entry-no-flag.rs
parentc6b883bb2eefd5377f2d75be95d8f20e271924ca (diff)
parenta6056bce92a8983f2bd3a8c9d03914bd4fb93c5a (diff)
downloadrust-8620e85a1ce15e213b30db3f130f7360f4c7396d.tar.gz
rust-8620e85a1ce15e213b30db3f130f7360f4c7396d.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 'tests/codegen/patchable-function-entry/patchable-function-entry-no-flag.rs')
0 files changed, 0 insertions, 0 deletions