Revert "Monomorphize calculate_dtor instead of using function pointers"

[bugadani]

Reverts #77755

There is a chance that this PR caused an unexpected slowdown. For some reason, the try and merge perf measurements differ significantly.

r? @Mark-Simulacrum

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit cd45acc with merge d56627bbd1379c41d40dcd6b463e1af38068fb3c...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: d56627bbd1379c41d40dcd6b463e1af38068fb3c (d56627bbd1379c41d40dcd6b463e1af38068fb3c)

[rust-timer]

Queued d56627bbd1379c41d40dcd6b463e1af38068fb3c with parent 6b9fbf2, future comparison URL.

[rust-timer]

Finished benchmarking try commit (d56627bbd1379c41d40dcd6b463e1af38068fb3c): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[bugadani]

Well at least this isn't the 1.x% regression it was measured to be. But, what was that, then? Also, does this mean a random PR got a positive perf result as well?

[Mark-Simulacrum]

Probably partially noise, partially other work may have fixed some of the regressions introduced then. I'm going to close this as I don't think it's worth reverting the original patch on performance grounds given these results.

Also note that the percentage here is "of" a different value, so comparing it directly is likely flawed anyway.