In most cases, yes. However, with some work we should be able to allow inlining across language boundaries as long as you're using clang to compile the C and C++. This is because rustc uses the same backend as clang (LLVM).
Though it may seem like this would be brittle, it's worth mentioning that this is how Servo eventually intends to interoperate with SpiderMonkey, so it will be a strategy that is well-researched and officially supported.
Yes, but it's a C++ API and includes a bunch of inline bits in the form of RAII classes and so forth.
Making those non-inline would be a noticeable performance hit.
Similarly, using the non-inline jsapi.h versions of the various inline stuff in jsfriendapi.h would be a noticeable performance hit: those were added for Gecko to use based on performance measurement and profiling.
The main place where this inlining is needed is in the DOM bindings, where pretty much anything you're doing is overhead on the path from JS to the actual implementation. This is especially noticeable when the actual implementation is fast (e.g. many getters in the DOM). In modern browsers the binding overhead is on the order of 2 dozen instructions or so. A non-inline function call takes... well, it depends on the ABI. On x86, with cdecl, you only have 3 caller-save registers but have to push all the args on the stack. On x86-64, with the AMD64 ABI (so everything except Windows), there's a ton of caller-save registers that might need to get pushed/popped around the call. Either way, the chance that you add noticeable overhead to an operation that's already <30 instructions is high. And that's if you only have to make one call. If you have to make _several_ such calls as part of the binding code, you're just screwed. And then you start adding APIs that compute and return all sorts of stuff in as single call (see the SpiderMonkey typed array APIs) and other such ugliness.
