WIP: Support for Embedded Swift (v2) #263
Conversation
sliemeobn
changed the title
|
also @MihaelIsaev, I think your EmbeddedFoundation package is a great idea and a great start. do you think you could add these from the wasi/musl libc as well, and add proper license attribution to your package? |
|
|
||
| // C bit fields seem to not work with Embedded | ||
| // in "normal mode" this is defined as a C struct | ||
| private struct JavaScriptValueKindAndFlags { |
There was a problem hiding this comment.
I think it makes sense to unconditionally use regular bit masking instead of bit fields even for non-Embedded mode for portability. Could you extract this refactoring as a separate PR?
There was a problem hiding this comment.
just to clarify, do you mean to use the swift-based "decoding" as I wrote here for embedded in general? (ie: just pass an "unsigned short" through the C shim?)
Examples/Embedded/Sources/EmbeddedApp/_thingsThatShouldNotBeNeeded.swift
Show resolved
Hide resolved
| @@ -234,3 +235,20 @@ func _free_host_function_impl(_ hostFuncRef: JavaScriptHostFuncRef) { | |||
| JSClosure.sharedClosures[hostFuncRef] = nil | |||
| } | |||
| #endif | |||
|
|
|||
| #if hasFeature(Embedded) | |||
| // cdecls currently don't work in embedded, and expose for wasm only works >=6.0 | |||
There was a problem hiding this comment.
There is no reason using cdecl instead of silgen_name here, so I think we can use silgen_name and call those functions with Swift calling convention. I'll address this after merging your change, so don't care about this comment, just a note for me.
|
I think it's a much mergeable approach. Happy to merge once CI passed and a few my concerns are resolved. Thank you for tackling on this! |
|
thanks for reviewing, I'll try address the comments later today, they all makes sense. the biggest issue with 5.10 compatibility I have right now is that the swift compiler seems to freak out about I'll try my luck with |
|
@kateinoigakukun with CI passing, are there any issues left you'd want me to address before considering a merge? |
|
Sorry I just missed the CI status update |
thanks to @MihaelIsaev for starting the other branch, I was inspired to try on my own by it.
I left String untouched (the entire JS runtime really), but I had to move a few things out of the C lib (ideally we can get rid of the entire thing eventually).
Also, the C header bit field with stuff does not seem to play well with Embedded (do not know why, pushed it into Swift for now)
there is an
Examples/Embeddeddemo that shows how it wants to be built.my hope is that, one day:
for now, a single unsafe flag needs to be added in the package.swift, and bundle resources do not work (SwiftPM will generate code for Foundation bundles).
In general, JavaScriptKit could use a bit of modernization and replace of all the "anys" with variadic generics.
Also, I don't see the value of using class hierarchies (does not play well with embedded) - but I tried to leave as much untouched as possible.
Promises, throwing functions, and typed arrays are left unsupported entirely for now, the rest should work with almost no API surface change.