encode generics_of for fields and ty params

[BoxyUwU]

Fixes #87674
Fixes #87603

ICE was caused by calling generics_of on a DefId without any generics_of results. This was happening when we call generics_of on parent DefIds of an unevaluated const when we evaluate it.

r? @lcnr

[eddyb]

@bors r+

[bors]

📌 Commit 8ff2ecc has been approved by eddyb

[lcnr]

r? @eddyb

[bors]

⌛ Testing commit 8ff2ecc with merge c4c2986...

[bors]

☀️ Test successful - checks-actions
Approved by: eddyb
Pushing c4c2986 to master...

[rylev]

This change seems to have caused regressions (albeit fairly minor) in several real world crates such as diesel, serde, and futures. The regression seems to be happening in the explicit_predicates_of query which I believe this change would likely impact.

As part of the performance triage process, I'm marking this as a performance regression. If you believe this performance regression to be justifiable or once you have an issue or PR that addresses this regression, please mark this PR with the label perf-regression-triaged.

@rustbot label +perf-regression

[eddyb]

One workaround, since the behavior should be quite predictable, would be to have a single generics_of query that is implemented in the same way for both local and cross-crate, for all the DefKinds that don't have their own generics, and then defer to the specific generics_of impls past that point.

However, adding two levels of queries may itself cause additional inefficiencies, so perhaps a more straight-forward fix would be to make the cross-crate generics_of not even try to decode the generics for certain DefKinds, and offer up the Generics we expect (i.e. just pointing to their parent).

[Mark-Simulacrum]

I investigated the suggested fix a little. It seems like it's probably not worth it for the small potential wins -- we'd have to do some pretty large scale refactoring, and for probably not that many DefKinds. It also seems uncertain that we'd end up winning -- decoding the largely empty generics should be pretty fast, I'd expect.

And if we look at cycles:u, with the new significance calculations, not too many benchmarks actually regressed. So I'm going to say this is probably an acceptable loss for the time being, given the correctness fix.

@rustbot label +perf-regression-triaged