Remove TrustedLen requirement from BuilderMethods::switch

[est31]

The main use case of TrustedLen is allowing APIs to specialize on it,
but no use of it uses that specialization. Instead, only the .len()
function provided by ExactSizeIterator is used, which is already
required to be accurate.

Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.

[rust-highfive]

r? @ecstatic-morse

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

[ecstatic-morse]

The other use of TrustedLen is when returning an incorrect value from ExactSizeIterator would cause UB from safe code. That seems to be the case here.

[est31]

It's not UB if the number is wrong. According to docs, it's only a hint for allocation:

Create a switch instruction with the specified value, default dest, and with a hint for the number of cases that will be added (for efficient allocation).

[ecstatic-morse]

Good catch! However, this is part of a trait signature (though it seems that LLVM is the only backend that implements it), so I think we should maintain the status quo here. Is there a reason you want this besides cleanup?

[est31]

Admittedly I wasn't aware of this guarantee that the trait gave, but I was lucky that it's not applicable :).

Yeah, neither cranelift codegen nor gcc-rust implement the trait, only the in-tree llvm codegen. Even if they used it, the API provided is unstable anyways, and it's not really hard to update. I had to spend a lot of time reading github discussions on what TrustedLen means and I think the new API is much more easy to handle because implementors don't have this mental burden of having to understand a poorly documented and niche feature of the language (which also has still unresolved questions in its tracking issue).

Btw the commit that introduced the TrustedLen was a similar cleanup commit: 35705de

[ecstatic-morse]

I'll defer to the original author then, although my preference is to close this. I don't think we should force implementers to handle cases where ExactSizeIterator lies. This signature allows them to assume len is accurate in unsafe code.

If that aspect of TrustedLen is unclear, perhaps the documentation could be improved?

[ecstatic-morse]

r? @bjorn3

[est31]

This signature allows them to assume len is accurate in unsafe code.

I wouldn't agree with that. #37572 lists the question what TrustedLen means for ExactSizeIterator as open question. The only thing that implementors can assume is that size_hint is accurate. The default ExactSizeIterator impl bases on that but there is no guarantee that the implementors don't override the default :).

[bjorn3]

It's not UB if the number is wrong. According to docs, it's only a hint for allocation:

Create a switch instruction with the specified value, default dest, and with a hint for the number of cases that will be added (for efficient allocation).

When I introduced the bound I assumed that it would be UB for the length to be wrong. Once cg_clif uses BuilderMethods it will not require TrustedLen either as cranelift_codegen::Switch doesn't need to know the size in advance. Because of this I don't have any objections to this change, but I will leave it up to someone else to decide if this should be merged.

[ecstatic-morse]

I don't think that the fact that TrustedLen is underspecified means we should start removing it from internal APIs. If you find someone who disagrees (perhaps someone who's more familiar with TrustedLen than I am?), you're free to ask for a different reviewer. I won't approve this without a better rationale.

[est31]

I don't think that the fact that TrustedLen is underspecified means we should start removing it from internal APIs.

Thankfully this PR has more justification than only that, in that TrustedLen is not required. What would you say if instead of an unused TrustedLen bound, there were an unused Clone bound?

Also note that this PR doesn't propose removal of all uses of TrustedLen in the compiler. In the other place where it's used, one I can't replace it this easily with ExactSizeIterator because latter doesn't support chaining. In this instance though, it's dead weight. Nobody needs the bound and it only confuses readers. The fact that the original reviewer would prefer review by a TrustedLen expert further proves my point :).

I'll r? @petrochenkov , maybe they are more amenable to simplification PRs :).

[petrochenkov]

Simpler is better.
@bors r+ rollup

(Also, nobody is going to return unreasonable numbers from ExactSizeIterator::len in practice, so it can be used as a hint pretty reliably.)

[bors]

📌 Commit 12ada5c has been approved by petrochenkov