Skip to content

GUFA: Fix string.encode#8812

Merged
kripken merged 3 commits into
WebAssembly:mainfrom
kripken:gufa.string.encode
Jun 8, 2026
Merged

GUFA: Fix string.encode#8812
kripken merged 3 commits into
WebAssembly:mainfrom
kripken:gufa.string.encode

Conversation

@kripken

@kripken kripken commented Jun 8, 2026

Copy link
Copy Markdown
Member

This writes to an array. Without noticing the write, we might think it
contains the wrong thing.

@kripken kripken requested a review from a team as a code owner June 8, 2026 17:21
@kripken kripken requested review from tlively and removed request for a team June 8, 2026 17:21
auto* set =
builder.makeArraySet(curr->ref, curr->index, get, MemoryOrder::Unordered);
// The index does not matter, as we do not track array indexes yet TODO
Expression* index = builder.makeNop();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like it would be easy to change some other code that would then trip over a none-typed index expression. Should we make this an i32.const 0 instead?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0 would be incorrect, though, which could lead to a subtle bug. a Nop doesn't even have the right type, so if this is actually used, it should error loudly.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'm sympathetic to failing quickly and loudly on errors, but I don't think a type error will be super obvious. Maybe some other sentinel would be better, like -2? (IIRC, -1 is used for descriptors.) I don't feel too strongly about this, though. I guess this ArraySet will only be visible in call stacks that include this function?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-1 or -2 are valid values, though - if we improve the analysis, it would be like we are actually writing there, which seems risky for correctness.

If we really want to make valid IR here, we could generate imported functions and put calls to them here. Then it would even be valid to print the module in the middle of the pass here. I think if we ever run into annoying issues here, we can consider that.

Comment thread test/lit/passes/gufa-closed-open.wast Outdated
(func $read (export "read") (result i32)
;; We could infer what the value is here, since there is only one write. TODO
;; Meanwhile, we should not infer a wrong value, even in closed world.
(array.atomic.get_s $array

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it matter that this is atomic? If not, we should make it non-atomic to simplify the test.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, thanks, this was just in the reduced testcase and I didn't notice it. I made it unatomic.

@kripken kripken merged commit bfe40fa into WebAssembly:main Jun 8, 2026
16 checks passed
@kripken kripken deleted the gufa.string.encode branch June 8, 2026 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants