Check whether vector value needs to be dropped in Vec#truncate

[KamilaBorowska]

Fixes #17633.

[rust-highfive]

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

[dtolnay]

LGTM and I think the severe O0 performance hit is worth fixing. Let me run it by one other person since this involves unsafe code:

[dtolnay]

r? @alexcrichton

[alexcrichton]

I'm personally wary and would prefer to not land changes like this in libstd at this time. I understand the tradeoff and how this performs much better at O0, but there are a number of aspects which give me pause:

• Primarily, this is nowhere near the only part of the standard library that could benefit from treatment like this. Practically the entire standard library is built on "unnecessary" abstractions that compile away and could be hand-coded much more efficiently at O0. I'm not really sure why we'd single out just one method to get fixed.

• Secondarily, this actually makes code at O0 somewhat worse in terms of codegen time. LLVM now has to emit this much more code (new branches) for all calls to this functions, and then LLVM has to emit code for all that.

Our somewhat ad-hoc-ly developed policy (AFAIK) is that we don't accept O0-only improvements into libstd, and I'd prefer to stick to that unless we can develop a policy to encompass more than just a handful of functions in libstd.

[KamilaBorowska]

Primarily, this is nowhere near the only part of the standard library that could benefit from treatment like this.

Agreed. Even then, I don't think it's a bad idea to do that in places that can benefit from it, even if there is much more to do.

Practically the entire standard library is built on "unnecessary" abstractions that compile away and could be hand-coded much more efficiently at O0. I'm not really sure why we'd single out just one method to get fixed.

Mostly because users actually workaround around that one. See kmeisthax/rapidtar@92f4af2

Secondarily, this actually makes code at O0 somewhat worse in terms of codegen time. LLVM now has to emit this much more code (new branches) for all calls to this functions, and then LLVM has to emit code for all that.

I.e. having more tokens in a source code slows down compilation. This is technically true, although mostly meaningless.

[alexcrichton]

I undertand how this would make linked code like above no longer necessary, but I continue to feel that this is not something we should do in libstd. Despite this being localized, this can easily snowball and has questionable value in returns. We've basically never tried to develop idioms for Rust where O0 runtime is fast, O0 is basically optimized for compile time speed and that's it.

Given basically any slow part of libstd that gets optimized away we can generate a program that "too slow" at O0, so I'm not sure we can place too much weight on any one example.

[scottmcm]

@xfix Is it possible your most recent force-push had the wrong content? This looks like a different change.

[KamilaBorowska]

Yes, that's what happened.

[Dylan-DPC-zz]

ping from triage @alexcrichton awaiting your review on this

[dtolnay]

I don't foresee Alex's perspective changing. #57949 (comment) are strong arguments.