Skip to content

fix(compiler): Write universal exports on linked module #2234

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

Merged
merged 1 commit into from
Apr 12, 2025

Conversation

ospencer
Copy link
Member

In #2104, the write_universal_exports function was previously called after linking, but I forgot to reinstate it. This restores that behavior.

I deleted some tests because they were testing old behavior that was valid for the intermediate (object) wasm files but are no longer valid in the output of final wasm modules.

@ospencer ospencer self-assigned this Jan 16, 2025
Copy link
Member

@spotandjake spotandjake left a comment

Choose a reason for hiding this comment

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

Mostly looks good just two small questions.

@spotandjake
Copy link
Member

spotandjake commented Jan 22, 2025

I was testing with this locally and I think we changed the behaviour of the start function.
The below program:

module Test

provide let _start = () => print("test")

when compiled with grain compile ./test.gr --use-start-section gives an error during compilation Fatal: Module::addFunction: _start already exists, oh actually interestingly I get that even if I omit the --use-start-section

We also get similar behaviour with provide let memory = () => 1 because of the memory section export.

@ospencer
Copy link
Member Author

@spotandjake Good catch. I restored the old behavior. We should maybe consider a warning for reserved export names, but that's not for this PR.

@spotandjake
Copy link
Member

spotandjake commented Jan 23, 2025

I just tried this again the _start stuff is fixed but I found a new bug if you have a program like:
b.gr:

module B

provide let x = (y) => 1

a.gr

module A
from "./b.gr" include B
provide let x = B.x

we seem to hit a Not_found exception.

It might also make sense to add regression tests for both the _start and example above.

I did some independent investigation on this and the problem is B.x is being imported as a global, and is in the export table as a global.

@ospencer ospencer force-pushed the oscar/fix-exports branch from aa96a3d to 98c4864 Compare April 12, 2025 01:12
@ospencer ospencer force-pushed the oscar/fix-exports branch from 98c4864 to efe5f4e Compare April 12, 2025 03:18
@ospencer
Copy link
Member Author

This is good to go. @spotandjake I added tests for that behavior and another test caught a different bug.

function_body,
);
// Remove existing Grain export (if any)
Export.remove_export(wasm_mod, name);
Copy link
Member

Choose a reason for hiding this comment

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

Why is the remove_export no longer necessary

Copy link
Member Author

Choose a reason for hiding this comment

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

When we used wasm files as object files, we wrote special Grain export names in the Wasm binaries to facilitate linking later. We don't do this anymore before linking happens before we generate wasm (so there was no Grain export in the first place to worry about removing).

},
) =>
let name = Ident.name(id);
let exported_name = "GRAIN$EXPORT$" ++ name;
Copy link
Member

Choose a reason for hiding this comment

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

Why is the GRAIN$EXPORT$ prefix gone?

Copy link
Member Author

Choose a reason for hiding this comment

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

We don't write special Grain exports anymore; now we only write the universal exports (see my other comment).

@ospencer ospencer added this pull request to the merge queue Apr 12, 2025
Copy link
Member

@spotandjake spotandjake left a comment

Choose a reason for hiding this comment

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

Looks good to me I had one small question, but otherwise lets get this merged.

@@ -3311,8 +3267,7 @@ let compile_main = (wasm_mod, env, prog) => {
if (Grain_utils.Config.use_start_section^) {
Function.set_start(wasm_mod, start);
} else {
ignore @@
Export.add_function_export(wasm_mod, grain_start, Comp_utils.grain_start);
ignore @@ Export.add_function_export(wasm_mod, start_name, grain_start);
Copy link
Member

Choose a reason for hiding this comment

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

Should we be doing a check here and warn and override if a user _start exists?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe, but that's not for this PR.

Merged via the queue into main with commit 2dba010 Apr 12, 2025
12 checks passed
@ospencer ospencer deleted the oscar/fix-exports branch April 12, 2025 06:12
@github-actions github-actions bot mentioned this pull request Apr 12, 2025
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.

3 participants