-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify and rename CrateItem
#34
Comments
@rustbot claim |
We indeed definitely need to add more helper functions and better printings, for |
Hmm... what items are crate items but have no mir? I thought we explicitly listed items that have mir |
If I try to get the body of all items, the following test crashes:
|
Oh 🤦 i'll look into it |
That said, I would expect CrateItems to return things that don't have body. Such as an external C function that was declared in the crate. |
Maybe we should rename it then. I think we're iterating over things with MIR |
We don't want to have both though, right? An option to get all items and an option to get all things with MIR. |
Depends on how useful a general "iterate over everything" system would be. We do have some ways to iterate over specific groups of items (e.g. over all impls, all traits, ...). If we iterate over all |
…rors Allow loading the SMIR for constants and statics cc rust-lang/project-stable-mir#34 before this PR we were ICEing when trying to access the SMIR of anything other than functions
Rollup merge of rust-lang#115749 - oli-obk:smir_consts, r=compiler-errors Allow loading the SMIR for constants and statics cc rust-lang/project-stable-mir#34 before this PR we were ICEing when trying to access the SMIR of anything other than functions
Allow loading the SMIR for constants and statics cc rust-lang/project-stable-mir#34 before this PR we were ICEing when trying to access the SMIR of anything other than functions
I wonder if we should rename |
Agreed that |
|
I kinda prefer That said, I am planning on creating a trait for things that have a |
BTW, I think it would be nice to clarify what No matter what we decide, I suggest that we add a constructor to be used in other places in our crate that ensures this item invariants hold. Something like: pub(crate) try_new(def_id: DefId) -> Result<Self> { /* todo */} |
CrateItem
CrateItem
I was trying to write a test that would traverse the body of every function in a crate, but I couldn't do that by only using StableMIR APIs.
Not every
CrateItem
is a function, and there is no method to retrieve information about the type ofCrateItem
, so users can't tell whether it's valid to retrieve the item body. If a user tries to get the body of a non-function, StableMIR crashes. Note that just knowing that an item is a function will likely not be enough, since there are cases where the function body might not be available.Besides providing more information about a
CrateItem
, we could also change the body ofCrateItem::body
to returnResult<>
instead.The text was updated successfully, but these errors were encountered: