rust-mozjs (specifically jsglue.cpp) fails to build on Windows with sccache. I have tested, and it has successfully built on Linux (WSL Debian).

Setup

1. Install sccache (v0.2.15)
2. Run set RUSTC_WRAPPER=sccache, and sccache --start-server
3. Run cargo clean --release
4. Run cargo build --release -vv > build.log

Actual Output: https://paste.gg/p/redfire/2c9d5dd64f724e8b806a8175653d75e5 (Expected Output is like 65K lines...)

I think I have narrowed it down to the build command for building jsglue.cpp. Expected jsglue.cpp build command flags (No sccache):

Actual jsglue.cpp build command flags (w/ sccache):

Edit: After looking around a bit, it seems that build.rs is being completely skipped, look at the flags that are missing. https://github.com/servo/rust-mozjs/blob/master/build.rs

The docs link an API Reference and a User Guide, both of which 404. What should they point to?

Similar to #544. The methods such as isNativeFun for JSFunction are not available. Thus, there is no way to check if a JSFunction is native, only if the function is native and is equal to a given native function.

RootedGuard<'_, T> requires that T implement mozjs_sys::jsgc::RootKind.

This issues involves exporting mozjs_sys::jsgc::* in mozjs.

Reason

Currently, I am unable to create a generic function that does this as this struct is not exported by mozjs. This will be useful for creating utility functions to set a value without requiring you to manually convert it using ToJSValConvertible.

Implementation Code

Currently, there is no way to convert a PropertyKey to a *mut JSString because the methods on PropertyKey are not wrapped. In the definition of PropertyKey, there are methods such as isString and toString, which would be helpful.

I am currently trying to implement a function which would output all of an object's keys as a Vec<String>, however, this is currently not possible.

Btw, I just noticed the Microsoft documentation link in line 1072 is 404 now.

I tried to search it but looks like I can't find exactly same one.

• https://docs.microsoft.com/en-us/cpp/code-quality/annotating-function-parameters-and-return-values?view=vs-2019
• https://docs.microsoft.com/en-us/cpp/cpp/reference-type-function-returns?view=vs-2019

But found 2 links might be related; ☝️ is any of them I should update to the comment?

Originally posted by @CYBAI in https://github.com/servo/rust-mozjs/pull/515#issuecomment-660416197

https://github.com/servo/servo/blob/da559d47b93854e4c7d4acf0a0d2029a9e643794/components/script/compartments.rs

We should bring the AlreadyInCompartment and InCompartment types into this crate (renaming them to AlreadyInRealm and InRealm in the process), and make the assert method take a *mut JSObject object instead. This will allow us to add a InCompartment argument to ToJSValConvertible, avoiding a source of crashes.

https://github.com/servo/mozjs/blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsapi.h#L520-L530

So this crate has a jsglue.cpp file, yet another one, with more stuff than the one in servo/mozjs, but mostly duplicated stuff. It has corresponding bindings in glue.rs, but this file is not generated by bindgen during the build, it's just sitting there in the repo, never regenerated, so it may not even be in sync anymore. The instructions to build it are a comment with hardcoded paths in the otherwise 8 years old file gen.py.

We then wrap those with additional Rust methods, through macro calls generated in glue_wrappers.in (and jsapi_wrappers.in because, why not?). Those files are generated by the shell script generate_wrappers.sh, which is just a sed script in disguise.

Those two .in files aren't generated during build-time either, and the jsapi one is generated from the generated bindings from servo/mozjs_sys, but the script is hardcoded to read the debug bindings, so who knows if that's correct when building in release mode…

How did we let things become that out of hand? What is actually relevant, and what is not?

https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/js/public/Class.h#841-842 https://github.com/servo/rust-mozjs/blob/124e5243a02ddaa879f2988313cee738c435f8b1/src/consts.rs#L26-L27

The crash occurs during the call to JS_GC, which suggests that the AutoGCRooter structure or CustomAutoRooter vtable is not correct for that arch.

It seems Runtime::new can be called successfully only once on a thread.

I get the Err result calling it a second time. This is on 0.9.2 on nightly-2018-10-12 on MacOS High Sierra.

Running this test passes if assign() is called once, fails when called twice.

Hi,

I've just started learning how to use these bindings, and a lot of what I learnt was purely from reading the tests. Having at least the methods in the rust module documented would be really helpful, together with tutorials for getting started.

For example, the runtime struct appears to do JS_Init, the creation of the runtime and also assigning a context to it, which I investigated because the latest version of this crate was missing bindings to the JS_NewRuntime and JS_DestroyRuntime functions. These functions show up on the documentation link but not in the latest version of the crate.

not clear how this error can be fixed without altering the source.

Currently we hard-wire a lot of configuration options, we should think about an API for setting them.

Both crates is build, mozjs test passed succesfull, but rust-mozjs failed. There are lot of 'undefined reference to' when i try to run tests. Example: /home/blacksmith/.cargo/registry/src/github.com-1ecc6299db9ec823/mozjs_sys-0.51.1/mozjs/js/src/jit/IonBuilder.cpp:14442: undefined reference to `js::jit::CompileCompartment::runtime()'

Also warning: cc1plus: warning: unrecognized command line option «-Wno-return-type-c-linkage» warning: cc1plus: warning: unrecognized command line option «-Wno-c++0x-extensions»

Seems that mozjs compiled using clang, but rust-mozjs compiled using gcc.

x86_64-pc-linux-gnu-5.4.0 clang-5.0.1

If we add a Cell<*mut Self> member to Heap<T> that is conditionally compiled, initialize it to null, and set it to self as *const Self whenever Heap::set is invoked, we can assert that the cell value is either null or equal to self as *const Self. This will automatically assert any time that a Heap value is set to a non-default value, moved (thus invalidating the pointer stored by SM), and set once more. This can't flag any moves that occur when no mutation follows, but it's better than nothing.

From an appveyor run:

It will be very similar to the ArrayBufferView typed array bindings.

The Handle stuff and whatnot are quite hard to use safely, they don't even have a lifetime, etc.

Its cx thing is a raw pointer that could be anything.

Rust has the ability to compile code with ASAN, and spidermonkey also supports being compiled under ASAN. However, as far as I can tell, if you compile rust-mozjs with ASAN, the spidermonkey code doesn't actually end up with ASAN.

It'd be great if ASAN were propagated down so that the dangerous C++ also was sanitized. Cheers!

It takes raw pointers and dereferences them.

Are there any simpler wrappers for https://github.com/servo/rust-mozjs ? I just want to load typescript.js, get ts variable, call ts.createNode function and a few other functions. I attempted to do that with a chakracore wrapper, but got stuck.