Skip to content

Conversation

juj
Copy link
Collaborator

@juj juj commented Sep 18, 2025

Fix --post-js scripts to execute after main() in MODULARIZE mode. Fixes test minimal0.test_unicode_js_library after this change: https://github.com/emscripten-core/emscripten/pull/23157/files#r1889243405

@juj juj changed the title Fix --post-js scripts to execute after main() in MODULARIZE mode Fix --post-js scripts to execute after main() in MODULARIZE mode in MINIMAL_RUNTIME Sep 18, 2025
be executed after main() has run.
Like "--pre-js", but emits a file *after* the emitted code. In addition to
being located after the emitted JS library code, --post-js code will also
execute only after main() has run.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this actually the behavior we want though?

Is this true today? I would have though that WASM_ASYNC_COMPILATION=1 (which is the default) means that the code runs before we run main (while the wasm file is loading).

Which behaviour do we think is more useful / expected?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In https://github.com/emscripten-core/emscripten/pull/23157/files#r1889243405 you had commented

This means that postjs code, which comes after main will now run after main like it would do with sync instantiation.

I think this is a pretty reasonable change.

so I wanted to highlight that as it is the behavior that the test suite depends upon.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I would also be ok to leaving this unspecified (it is a code size increase in MINIMAL_RUNTIME after all, and not all users might need that guarantee). Although I wonder if that fights against the ChangeLog note in that PR

One side effect of this is that code in --post-js files will now be delayed until after module creation and after main runs. This matches the existing behaviour when using sync instantation (-sWASM_ASYNC_COMPILATION=0) but is an observable difference. (#23157)

that mentions this to be the new behavior.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess maybe we should be consistent, but for now it seems like -sMODULARIZE has already been updated to have the well-defined behaviour of running post-js after main.

For code built without -sMODULARIZE it currently depends if you build with async compilation or not, so its not as simple as saying that post-js code always runs after main.

So, perhaps revert the documentation change here until and we can separately consider how to document the current differences between modes (or remove them and then document the consistent new behaviour)?

Documenting this as always being one way would currently be inaccurate I think?

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

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

lgtm % docs question

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

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

Do we perhaps have an existing test that verified this behaviour that we can now run in minimal runtime mode?

@juj juj force-pushed the minimal_runtime_post_js branch from b3aebfa to eb58b29 Compare September 19, 2025 19:32
@juj
Copy link
Collaborator Author

juj commented Sep 19, 2025

Do we perhaps have an existing test that verified this behaviour that we can now run in minimal runtime mode?

Yes, the test test_unicode_js_library which changed semantics in https://github.com/emscripten-core/emscripten/pull/23157/files#r1889243405 can be used to verify this, e.g. minimal0.test_unicode_js_library.

If this is the only test in the suite that depends on this behavior, then I think another way to resolve this test failure is to change the test or verify a --pre-js instead of a --post-js. The test intent in test_unicode_js_library is only to verify that inputting UTF8-encoded files in --post-js works. So one could reasonably assume that if UTF8 works in --pre-js, then it'll work in --post-js as well; and change the test to verify --pre-js instead.

@juj juj force-pushed the minimal_runtime_post_js branch from eb58b29 to 033194e Compare September 19, 2025 19:36
@sbc100
Copy link
Collaborator

sbc100 commented Sep 19, 2025

minimal0.test_unicode_js_library

Can you add this test at line 708 of .circleci/config.yml to confirm the fix then?

I agree the intent of this test does not seem to be explicitly checking/verifying this ordering, but I'd be happy to land this with that tests as confirmation. Alternatively you write a specialized new test for just this, but we can also do that as a followup when/if we decide to lock down the beaviour in all configurations.

#if PTHREADS || WASM_WORKERS

#if MODULARIZE
await instantiatePromise;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe one day we can find a way to clean this up and just use async/await instead of have this global instantiatePromise.

lgtm for now though.

self.cflags += ['-sMODULARIZE', '--js-library', test_file('unicode_library.js'), '--extern-post-js', test_file('modularize_post_js.js'), '--post-js', test_file('unicode_postjs.js')]
# In addition to verifying that --post-js files can contain UTF8 characters,
# this test verifies a specific semantic that in -sMODULARIZE mode, the
# content in --post-js files should be executed only after main() runs.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you reference the bug I just created here: #25346

@sbc100
Copy link
Collaborator

sbc100 commented Sep 23, 2025

Do you want to land this or wait for us to resolve #25346 (since it may change the behaviour here)

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