This makes IDEs, documentation generation tools, and linters handle our
generated files better. I set the project root to be `src` instead of `src/js`
so that it is allowed to import files directly from `src/core`. This way we
don't have to copy `error_handling.ts` we can just import
`../core/error_handling`.
I made a new folder called `src/js/generated` to place generated files into and
added typescript resolution rules so that when we import a file called
"generated/blah" we first look for `blah` in `src/js/generated` and then fall
back to a file called `blah` in `src/core`.
This also allows us to move around fewer files when building the docs
and in the makefile.
It seems that there is a bug in table instructions in Safari 16.3 which is used in the safari tests
but that Safari 16.4 has fixed it. xcode 15.0.0 uses Safari 16.6 which does not have the bug.
This change switches to my external implementation of hiwire. This is the
minimal change set to do this, it uses some hacks to avoid changing any files
outside of `hiwire.{c,h,js}`. In followups, I will gradually switch to using
the new APIs rather than compatibility shims.
Uses the JS Promise integration stack switching API to allow blocking for JavaScript promises and
`PyodideFuture` objects. It's a bit complicated...
This doesn't include support for reentrant switching, currently doing that will corrupt the Python VM.
One of the cpython tests (test_plistlib.TestBinaryPlistlib.test_deep_nesting)
seems to be extremely sensitive to stack utilization and stack overflows in our
CI when even a tiny amount of extra stack is used. I doubt this is a problem in
real life -- I certainly cannot reproduce it outside of the CI service. But this
rearranges the code to avoid any additional stack usage so that CI will pass.
This is a minor rearrangment.
I renamed "continuations" stuff to "stack_switching" and made a new folder
for stack switching logic. I also added logic in esbuild.config.mjs to calculate
which functions exported from stack_switching.mjs and automatically copy them to
Module and into the Emscripten namespace. This makes unit testing a little neater
since there is no modification of the Module object.
If wasm exception handling is available, use dynamically generated modules
with wasm exception handling for the invoke stubs instead of a JS trampoline.
This is useful because JS trampolines interact poorly with JS Promise Integration.
In the future, we should switch exception handling ABIs to the compiler-provided
wasm exception handling ABI and we can remove this code. Currently we are
blocked on using compiler-provided wasm eh by Rust support.
Resolves pyodide#4126.
If someone builds emsdk outside of the docker image and then attempts to use it
inside, there will be an error. This detects it and tells people to clean emsdk.
pfebrer