Vtable Metadata

[ssyram]

Following #839 , this PR is also split from #762 . It contains the part of vtable support series for computing the meta-fields of vtable, i.e., the size, align and drop fields. This PR adds a new pass compute_vtable_metadata for this purpose.

The former two fields read the data from the layout of the type definition (possibly unavailable).

The tough part is the drop field, where for some built-in data, e.g., arrays & tuples, the drop functions are newly implemented to recursively traverse the internal data to call the potential drop functions.

[Nadrieril]

At least the drop part should be done during translation so that we can reuse everything that already knows how to fetch/generate Drop impls. I entirely disagree with the amount of logic you've added to handle drops; because you use AI I cannot trust any line of this to be correct. I have therefore not wasted my time by trying to understand it. Please split this into multiple PRs that each does something small that I can review, and reuse existing logic instead of rolling your own.

Maybe I'm wrong and dismissing your PR too quickly. If that's the case, please explain in the top of your PR why you chose to do things like this, what other options you considered, and how you made sure that the logic you generated is correct as per rust semantics.

[ssyram]

Well, no, I put much time in implementing the drop logic myself -- AI generates the framework, which could not be used. So I hand implemented the recursion logic. I would quite strongly disagree with that you denied my efforts so quickly and this strongly and claimed it to be made by AI without even trying to understand. I myself tried quite hard to avoid troubles from AI and checked these parts myself. At least I made sure the test cases reflected correctly. This should show my efforts.

As for the drop, the main part is about dropping the arrays and tuples. There is no logic for this right? We are now implementing the shim, which does not exist in the Rustc. So it could split the logic clearly in a pass instead of working during the translation, which requires the Charon, but actually we cannot rely on.

Recall that Rustc does not have vtable method shims and we have to generate the shims ourselves. This is likewise the case for drop shims? Or, is there chances we get the drop function for the actual array or tuple types directly? If so, we can get rid of the drop logic, which essentially traverses the array or tuple types recursively and calls drop on those with drop functions.

[Nadrieril]

After lengthy discussion in DMs, I would like to publicly apologize for dimissing your PR out of hand, and I will also close this PR for not being acceptable for the various reasons I mentioned in DMs.

#844 provides a lot of the functionality you were implementing here, except for the drops. The drop impls for arrays and tuples you add here look valuable, I'd welcome a PR that adds them in a robust way.