Replies: 1 comment
-
|
Yes. It's a problem of the current design. I've decided to do so originally following the design of Inkwell so that we can represent a graph of operations just like a graph at the level of Rust codes. For example, when we have mutable references instead of immutable ones in those places, we need to write: let value = block.append_operation(operation).result(0).unwrap().into();
block.append_operation(func::r#return(&[value], location));rather than: block.append_operation(func::r#return(
&[block.append_operation(operation).result(0).unwrap().into()],
location,
));because Rust doesn't allow referencing mutable references at two locations at the same time for linearity. You can see previous notes and discussions about it in those tickets:
As described in #24, we haven't decided the best solution. But if you have any ideas or opinions, we would like to hear that! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I was a bit surpised that
module.body().append_operationdoes not require a mutable reference. I am not that familiar with MLIR internals yet but the unsafe block insideappend_operationdoes appear to be mutating the body.Can we make this safer by switching to a mutable reference or am I missing something?
Beta Was this translation helpful? Give feedback.
All reactions