Alexa VanHattum (Jan 05 2023 at 16:19): Alexa VanHattum (Jan 05 2023 at 16:19):I'm working on updating the verification engine to use this Sema changes that save names from this PR. One hiccup is handling names for let blocks. Since the bindings are truncated after evaluating the let body (e.g., this line), can variable IDs be reused across multiple (non-nested) let blocks?
Seems like we will need to do our own scoping on the verification side to handle this, which is fine, just wanted to confirm that this is what happens with the VarId mapping. Thanks!
CC @Jamey Sharp
Jamey Sharp (Jan 05 2023 at 18:23):Uh. I didn't think about the implications of that truncate when I wrote that PR. I think we should just revert part of the PR and put the next_var field back so that VarIds are unique within a rule. It should be a very small patch since now we can just manage next_var inside the add_var function.
Jamey Sharp (Jan 05 2023 at 18:42):Okay, it's not quite so easy to fix as I hoped, since truncating also throws away the names I was trying to save for you (and, eventually, for me too!). I think BoundVar should keep some notion of which scope the name was bound in, and Bindings::lookup should respect that, rather than truncating bindings.seen anywhere. I'm still thinking through the details...
Alexa VanHattum (Jan 05 2023 at 18:51):Got it, I'll also add this to the agenda for our next meeting. Thanks!
Jamey Sharp (Jan 05 2023 at 23:56):I'm out of time for today and haven't figured out precisely how to fix this yet. I can say for sure though that I don't want you to have to walk the AST again to get the names out. We should be able to expose the right information from sema, I'm just having trouble thinking through the details.
Jamey Sharp (Jan 06 2023 at 01:57):Actually, after taking a break, suddenly it seemed much easier: https://github.com/bytecodealliance/wasmtime/pull/5538
Last updated: Nov 22 2024 at 17:03 UTC