-
Notifications
You must be signed in to change notification settings - Fork 62
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
Multiple borrows in InstrSeqBuilder.if_else() #166
Comments
With the API as it currently is, there is no easy workaround other than I think if we had an |
Or maybe |
It's okay as long as I'm not missing something obvious; after some fooling around it turns out the Having an |
Summary
I feel awfully silly about this but I seem to have a trivial problem with
InstrSeqBuilder.if_else()
that seems bonkers but I can't figure out a way around it. ...well, that's a lie, I'm pretty sureRc<RefCell<T>>
would fix it but that shouldn't be necessary here so it Feels Wrong(tm).I'm writing a compiler that outputs wasm using
walrus
. I'm inoutput_expr(bcx: &mut Backend, locals: &Locals, ir: &Ir)
which is just a big match statement over the intermediate representation, which is currently just a slightly-lowered AST.Backend
contains thewalrus::Module
, which has to get passed in so that, at the very least, local variables can get looked up and added as necessary.Locals
is an index helping keep track of what local variable is where, as well as debugging info like names.The guilty code is just this:
The PROBLEM is that
Backend
gets borrowed mutably in each thethen
andelse_
closures. There's no way to pass it to the closures as an argument, and there's no way I'm aware of to really explain that the lifetimes of the closures don't really overlap. As you can see I already have to split theLocals
index apart into several ones, let each get populated, and then merge them back together, and now that I think of it that's probably the wrong approach....but I don't see what other approach I can do, and so I'm feeling like I'm missing something stupid, some option or trick or method in
walrus
. Because as it is I think you'd have the same problem in anything that might ever have to mutate state during the closures passed toif_else()
.Additional Details
I've simplified the code to its essence, or tried to at least. Full code is here: https://hg.sr.ht/~icefox/garnet/browse/src/backend.rs?rev=default#L185 . Very incomplete though.
The text was updated successfully, but these errors were encountered: