As alternative to workers, it's possible to implement threads as coroutines with javascript promise integration. This is what I've done on my sorvi platform. Downside is that javascript promise...
microblaze(el)-linux and sh(eb)-linux arch bits' (#35625) from alexrp/zig:microblaze-superh into master
std.lang.Type' (#35234) from Der_Teufel/zig:soa-builtin-type into master
What about the rework specifically makes it so that generating/merging compile_commands fragments from compiler calls could be done outside of build.zig/Zig?
With the build system rework, generating compile_commands.json should not need any support in build.zig or zig itself. It would also make it possible for clangd and such be able to use zig's...
Yeah this is all reasonable. The scope is pretty clear to me now.
I was mainly wondering how far this zig abi definition goes. So there is still the arch-os specific baggage, and -zig would only define the libc bits?
For example x86_64-linux-zig and x86_64-windows-zig would call the zig ABI functions the same way. For -freestanding it is often what compiler decides to do (usually the same as linux).
Would this also define consistent calling convention?
Updated my project to 0.16 and hit this too. Seems to affect any extern call. Wasm for example here.
What's the policy on other. I'm not quite sure what it would mean there.