One JS::Compile function takes SourceBufferHolder. In bug 1485800 SBH will become either UTF-8 or UTF-16, so that entrypoint will (ultimately) always parse in the most optimal way. But the other entrypoints take either Latin-1 or UTF-8, and if we just change the guts to parse UTF-8 the natural way, we will change a whole swathe of behaviors -- IMO a little too quickly. We want to be able to change a few things and get good feedback on correctness, then change more, then gradually opt all of SpiderMonkey and all of Gecko into using UTF-8-specific compilation wherever possible. Separate entrypoints that *only* take UTF-8 (and do not inflate to UTF-16, as happens now for both the UTF-8 and Latin-1 cases) will allow for explicit transition to accepting UTF-8 in specific places. While most of this bug is plumbing, I expect it will also add at least one major user of such an API or APIs -- likely in the JS shell, possibly hidden behind a command line flag to the shell (or disabled by such).

This bug may be outliving its usefulness, as I do this work piecemeal in other bugs, generally as JS::CompileUtf8DontDeflate-named functions until all the bugs have been worked out of the actually-UTF-8 path. But for now I will leave it around and open.