787580, 789551, 789633, 789637, 791022, 794667, 798624, 802347, 808181, 858108, 861281, 879079, 884283, 884371, 884410, 887563, 896280, 896540, 897484, 899973, 900674, 900986, 903352, 906940, 912581, 916993, 917295, 917296, 917798, 917843, 918118, 918373, 928507, 929314, 930782, 931446, 933810, 933834, 933946, 934557, 942453, 959787, 961077, 963167, 965830, 969798, 969812, 972385
This is a meta bug to track the various pieces of work that will be required. The primary goal of this work is to expose enough C++ Type Information in the JS API to make the browser GC-safe-by-default without making it impossible for Rust to generate C wrappers. The secondary goal is, of course, to have a nice API, although this bug is unlikely to get us all the way there. The plan: begin putting bits of our API into js/public while converting them one interface at a time to type-safe C++. These new bits will be #included into jsapi.h so that we don't have to do a massive jsapi.h -> js/api.h conversion until the very end. At the same time as we convert the methods to C++, we will create trivial, implementation-hiding C shims as js/public/c_<foo>.h. These shims will *not* be included into jsapi.h. Each patch in this series should move one discrete block of interface and handle the (hopefully simple) browser changes at the same time.
No new shim files should be necessary. The only parts of the API which are really C++ dependent are the roots, handles and mutable handles, and creation/destruction of those can be emulated with some C functions. See JS_CreateHandleObject etc. in jsapi.h; this style of API is gross but should be fine for use in wrapper/glue code.
Ah, I had not seen that you've already added those! In that case, yes, we should definitely do it that way.
Oh, also, those methods don't actually have an implementation, but that shouldn't be hard. I think that allocating storage out of tempLifoAlloc would work.
All depending bugs are closed, so this one can close, too, I assume.
There are still a few more bits of problematic API to cover, but nothing that needs to block exact rooting. Congrats to everyone involved.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.