Continue work on associated const equality

[JulianKnodt]

This actually implements some more complex logic for assigning associated consts to values.
Inside of projection candidates, it now defers to a separate function for either consts or
types. To reduce amount of code, projections are now generic over T, where T is either a Type or
a Const. I can add some comments back later, but this was the fastest way to implement it.

It also now finds the correct type of consts in type_of.

---

The current main TODO is finding the const of the def id for the LeafDef.

Right now it works if the function isn't called, but once you use the trait impl with the bound it fails inside projection.
I was hoping to get some help in getting the &'tcx ty::Const<'tcx>, in addition to a bunch of other todo!()s which I think may not be hit.

r? @oli-obk

Updates #92827

[bors]

☔ The latest upstream changes (presumably #93095) made this pull request unmergeable. Please resolve the merge conflicts.

[JulianKnodt]

Hm, after naively adding in Term instead of being generic over Ty and Const, I feel pretty strongly that it makes a lot of sense for now to special case the few branches where const is hit. If you feel pretty strongly that it should be a term, I can still do that, but I do think it would be a better idea to have it not be an enum.

[bors]

☔ The latest upstream changes (presumably #93352) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

Yea, I like this a lot more than the previous version, thanks for trying it out!

You accidentally included a cargo submodule update.

[oli-obk]

Hm, after naively adding in Term instead of being generic over Ty and Const, I feel pretty strongly that it makes a lot of sense for now to special case the few branches where const is hit. If you feel pretty strongly that it should be a term, I can still do that, but I do think it would be a better idea to have it not be an enum.

Hmm... can you point me to the source of examples that you think are unreachable for constants (or is it just those that now have .ty().unwrap() added in this PR?

[JulianKnodt]

It's mostly the points where there are ty().unwrap()s. I also feel it's both safer in terms of previous code still working, and also more efficient since it won't have to do pattern matching and require extra storage in the cache. I do realize it is significant code bloat tho, so I can avoid it, it might just be that my usage of golang has been getting to my brain

[bors]

📌 Commit 78fb74a has been approved by JulianKnodt

[JulianKnodt]

@bors r+
r? @oli-obk

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Change Termination::report return type to ExitCode #93442

[bors]

📌 Commit 78fb74a has been approved by JulianKnodt

[JulianKnodt]

I'm not sure if that's how it's done but I hope it's fine?

[mati865]

@JulianKnodt it's @bors r=oli-obk

[bors]

@mati865: 🔑 Insufficient privileges: Not in reviewers

[oli-obk]

@bors r-

[oli-obk]

@bors r+

Sorry about the lack of instructions.

[bors]

📌 Commit 78fb74a has been approved by oli-obk

[JulianKnodt]

my bad, I should've asked before just doing

[bors]

⌛ Testing commit 78fb74a with merge 1ea4851...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 1ea4851 to master...

[rust-timer]

Finished benchmarking commit (1ea4851): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression