Add way to differentiate locals that are function arguments from other locals #47
Comments
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 26, 2023
Rollup merge of rust-lang#117095 - klinvill:smir-fn-arg-count, r=oli-obk Add way to differentiate argument locals from other locals in Stable MIR This PR resolves rust-lang/project-stable-mir#47 which request a way to differentiate argument locals in a SMIR `Body` from other locals. Specifically, this PR exposes the `arg_count` field from the MIR `Body`. However, I'm opening this as a draft PR because I think there are a few outstanding questions on how this information should be exposed and described. Namely: - Is exposing `arg_count` the best way to surface this information to SMIR users? Would it be better to leave `arg_count` as a private field and add public methods (e.g. `fn arguments(&self) -> Iter<'_, LocalDecls>`) that may use the underlying `arg_count` info from the MIR body, but expose this information to users in a more convenient form? Or is it best to stick close to the current MIR convention? - If the answer to the above point is to stick with the current MIR convention (`arg_count`), is it reasonable to also commit to sticking to the current MIR convention that the first local is always the return local, while the next `arg_count` locals are always the (in-order) argument locals? - Should `Body` in SMIR only represent function bodies (as implied by the comment I added)? That seems to be the current case in MIR, but should this restriction always be the case for SMIR? r? `@celinval` r? `@oli-obk`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be nice to be able to differentiate between locals in a function that correspond to arguments (& return values) and other locals. This kind of functionality would be useful for computing function summaries. As mentioned in a Zulip thread, this information is not available yet in stable MIR. However, it does appear to currently be the case that local 0 is the return local, and the next N locals are the function's arguments.
One approach could be to return the number of arguments to a function (n). The return local could then be retrieved by indexing the 0th local, while the arguments could be retrieved by slicing the 1st to nth locals.
Alternatively, an API could be added to return both the arguments and the return values. Such an API could abstract over the actual implementation of the return and argument layout in locals.
The text was updated successfully, but these errors were encountered: