Make BytecodeCompiler able to handle UTF-8 source text

RESOLVED FIXED in Firefox 65

Status

()

enhancement
P2
normal
RESOLVED FIXED
6 months ago
5 months ago

People

(Reporter: Waldo, Assigned: Waldo)

Tracking

Trunk
mozilla65
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 wontfix, firefox65 fixed)

Details

Attachments

(29 attachments, 1 obsolete attachment)

3.89 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
904 bytes, patch
tcampbell
: review+
Details | Diff | Splinter Review
926 bytes, patch
tcampbell
: review+
Details | Diff | Splinter Review
2.53 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
2.03 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
3.81 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
1.60 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
1.12 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
2.32 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
8.07 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
2.09 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
1.64 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
9.64 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
3.79 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
3.12 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
5.04 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
10.56 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
1.34 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
31.89 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
10.90 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
8.39 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
2.40 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
1.72 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
1.07 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
56.78 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
7.80 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
6.26 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
2.32 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
5.55 KB, patch
tcampbell
: review+
Details | Diff | Splinter Review
(Assignee)

Description

6 months ago
Mostly this just involves a bunch of refactoring of BytecodeCompiler.* to separate out the stuff that deals with SourceBufferHolder from the rest of it, to reduce demand for doubling up of stuff.  Patches mostly done, still a little to go before ready to review.
Priority: -- → P2
(Assignee)

Comment 1

6 months ago
Dumping here just because.
Attachment #9020991 - Flags: review?(tcampbell)
(Assignee)

Comment 2

6 months ago
If there's a reason for this, and it's hard to imagine one, it's not documented, so undo this.  (Also jstests/jit-tests passed with this in place, so...)
Attachment #9020992 - Flags: review?(tcampbell)
(Assignee)

Comment 3

6 months ago
In hindsight I'm not sure this does anything, but I think it might mean the earlier two calls are unified at some point in this patch stack.  If not, it makes clear the lack of ordering dependency.
Attachment #9020993 - Flags: review?(tcampbell)
(Assignee)

Comment 4

6 months ago
More hindsight, I'm not entirely sure this survives to the end of the queue either, but it's not worth the trouble to undo it given it's so small.
Attachment #9020994 - Flags: review?(tcampbell)
(Assignee)

Comment 7

6 months ago
This cleanup does simplify some stuff tho.
Attachment #9020997 - Flags: review?(tcampbell)
(Assignee)

Comment 8

6 months ago
Attachment #9020998 - Flags: review?(tcampbell)
(Assignee)

Comment 9

6 months ago
It's tidier/more readable not to rely on overload resolution.
Attachment #9020999 - Flags: review?(tcampbell)
(Assignee)

Comment 10

6 months ago
I think I might end up undoing this later as well, but it's again too much trouble to undo.  (I keep saying this, and it really is -- problem is I have umpteen patches to BC.cpp atop this, and one tweak cascades through the entire thing because I touch so much of the file.)
Attachment #9021000 - Flags: review?(tcampbell)
(Assignee)

Comment 11

6 months ago
At the end of all these maybe it's worth adding the usual trailing underscores -- but no sooner, given I keep touching everything.
Attachment #9021001 - Flags: review?(tcampbell)
(Assignee)

Comment 12

6 months ago
Not sure why it would/should be any other way.
Attachment #9021002 - Flags: review?(tcampbell)
(Assignee)

Comment 13

6 months ago
BC has some mode-specific stuff in it that really belongs in subclasses, or passed in by callers.  This is the first bit of that.
Attachment #9021003 - Flags: review?(tcampbell)
(Assignee)

Comment 14

6 months ago
Eventually these subclasses disappear -- we gotta keep parser/sourceBuffer in a Unit-parametrized place -- but for now these are small simple transformation that move us the right direction.
Attachment #9021004 - Flags: review?(tcampbell)
(Assignee)

Comment 16

6 months ago
Ignore the FooBytecodeCompiler names -- I rename them to FooInfo by the end of these patches.  (Well, except BytecodeCompiler itself because it's too much pain til all this lands.)

Interesting how enclosingScope is always the same thing, so this gets rid of an extra frob that's always set the same.
Attachment #9021006 - Flags: review?(tcampbell)
(Assignee)

Comment 19

6 months ago
Sorry this one ends up being a bit of a mess.  :-(  I spent much of the weekend trying to clean it up some, and I did succeed some, but not some enough for my tastes.

The important thing here is, the *Info classes need/want to be usable regardless of source-text type.  We want to be able to fill them out once, for two arms of compilation, in some places.  So the Compiler classes hold all Unit-ful stuff, and they're distinct and not inheritance-related to the Info classes.
Attachment #9021009 - Flags: review?(tcampbell)
(Assignee)

Comment 20

6 months ago
This is separate from the previous step for mildly better readability.

Post hoc note -- parser/syntaxParser should be trailing-underscored, and they would if this were new code, but the existing code does use parser everywhere, so I didn't want to rename and make life painful for me in the patch-stack.  Like renaming BC, renaming these should wait til everything's landed.
Attachment #9021010 - Flags: review?(tcampbell)
(Assignee)

Comment 21

6 months ago
Exposing only functions that take a GlobalScriptInfo& passed in/created byt eh caller is at the end of this road.  But one step at a time, and this doesn't have to touch callers to work.
Attachment #9021013 - Flags: review?(tcampbell)
(Assignee)

Comment 22

6 months ago
setSourceCopy is called outside the file it's defined in, if memory serves, so it requires explicit instantiation.
Attachment #9021016 - Flags: review?(tcampbell)
(Assignee)

Comment 24

6 months ago
I haven't explicitly tested this all yet, but I think it should get the job done.  It *does* allow some tests (with later patches in place) to pass under UTF-8 parsing, so there's that.

We could debate about exactly what tradeoffs to make inside append(const Utf8Unit*, size_t).  I picked a way to make it work to start that's reasonably simple and stupid and Gets The Job Done For Now.  We can revisit exact approach later if necessary.  No need for omphaloskepsis now.
Attachment #9021028 - Flags: review?(tcampbell)
(Assignee)

Comment 25

6 months ago
Through the Magic of Templates, this Just Works!  "what have we done"
Attachment #9021029 - Flags: review?(tcampbell)
(Assignee)

Comment 26

6 months ago
This exposes BC to users, so they can fill in a bunch of stuff on the stack in cases where *either* UTF-8 or UTF-16 will happen later, and you want to share filling-in beforehand.  It does a proper file-copy and all.  It also is the super-easiest thing to break with changes made to prior patches.  :-|  Forebearance in making requested changes to prior patches, maybe after this one if it's easier, would be appreciated.

End goal is BC, ScriptInfo, EvalScriptInfo, GlobalScriptInfo, ModuleInfo, StandaloneFunctionInfo will be in the header -- and so will Compile* functions that take (*Info&, SourceText<Unit>&, ...) and do the unit-specific work.  I could have kept building in BC.h, but a separate header seems cleaner.  End of day, probably all of BC.* can be moved elsewhere or whatever.  But currently BC.* is a bit of a mess, and smaller more focused stuff is better IMO.
Attachment #9021031 - Flags: review?(tcampbell)
(Assignee)

Comment 27

6 months ago
The first new-style overload.  Removal of old-style and callers happens separately.
Attachment #9021032 - Flags: review?(tcampbell)
(Assignee)

Comment 28

6 months ago
...or maybe the previous patch did rewrite all callers.  Never mind.

Note that I'm really not caring about whether both Unit parametrizations actually *happen*, just making it possible to have both happen whenever Compile* overloads for both unit types are needed.  It may well be that EvalScriptInfo never needs a UTF-8 variant -- eval text coming from strings that are either Latin-1 or UTF-16, and the former I think is always inflated to the latter right now, and maybe even should be.  But, if we never instantiate for UTF-8 now, we never get UTF-8 now, so it doesn't hurt generalizing stuff.
Attachment #9021033 - Flags: review?(tcampbell)
(Assignee)

Updated

6 months ago
Blocks: 1503104
(Assignee)

Updated

6 months ago
Depends on: 1503086
(Assignee)

Comment 30

6 months ago
Try run of all the patches I bombed you with last night:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d63c67476c9778520d623a1fb374c3c52bf97494
(Assignee)

Comment 31

6 months ago
Okay, most of the orange is from missing one |- 1| in the initial patch for bug 1493441.  Bizarrely, jstests/jit-tests do not exercise *at all* compressed source.  Not sure why, and I timed out trying to figure it out earlier today.

More try-running with that fixed is significantly greener, yet turning up some issues that I *may* have fixt in this push:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6ece5a083389e01a5b6b041d72b5775f99bf4745

but we'll see.  (And notably there's some Rust change that I haven't been able to get to work locally, that might still need tweaks -- but it's also tier2, so there's that.)
(Assignee)

Comment 32

6 months ago
Okay -- I think everything the try-pushes flagged should be fixed now.  New try-push of this bug and a mess of others:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=736aa614eacd94a11f563f8f0a72464721a77f54

with all the relevant log of changes in this push:

https://hg.mozilla.org/try/pushloghtml?changeset=736aa614eacd94a11f563f8f0a72464721a77f54

(obviously starting where my changes start -- ignore the clang-plugin change, it's not relevant to any of this).

Mostly every patch here did have to be adjusted for the removal of the silly |LifoAlloc& alloc| argument to BytecodeCompiler, but the changes -- aside from being a very very very slow rebase -- were essentially mechanical and didn't fundamentally break anything in these patches.  If you want to see what I have post-changing, look at the try-push, but it doesn't seem necessary to bugspam every patch again here for not-interesting changes.
Attachment #9020991 - Flags: review?(tcampbell) → review+
Comment on attachment 9020992 [details] [diff] [review]
When compiling a module script, create the ModuleObject after creating the script for it

Review of attachment 9020992 [details] [diff] [review]:
-----------------------------------------------------------------

Order does not appear to matter.
Attachment #9020992 - Flags: review?(tcampbell) → review+
Attachment #9020993 - Flags: review?(tcampbell) → review+
Attachment #9020994 - Flags: review?(tcampbell) → review+
Attachment #9020995 - Flags: review?(tcampbell) → review+
Attachment #9020996 - Flags: review?(tcampbell) → review+
Comment on attachment 9020997 [details] [diff] [review]
Move script creation into prepareScriptParse

Review of attachment 9020997 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/frontend/BytecodeCompiler.cpp
@@ +52,4 @@
>  
>      // Call this before calling compile{Global,Eval}Script.
>      MOZ_MUST_USE bool prepareScriptParse() {
> +        return createSourceAndParser(ParseGoal::Script) && createScript();

Ehh.. I guess this is what our style rules say but gives a bit of a whiff of hiding side-effects in conditionals. Oh well, it's fine.
Attachment #9020997 - Flags: review?(tcampbell) → review+
Attachment #9020998 - Flags: review?(tcampbell) → review+
Attachment #9020999 - Flags: review?(tcampbell) → review+
Comment on attachment 9021000 [details] [diff] [review]
Split BytecodeCompiler::compileStandaloneFunction into BytecodeCompiler::{parse,compile}StandaloneFunction

Review of attachment 9021000 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/frontend/BytecodeCompiler.cpp
@@ +70,5 @@
>          return createSourceAndParser(ParseGoal::Script, parameterListEnd);
>      }
>  
> +    // Call this before calling compileStandaloneFunction.
> +    CodeNode* parseStandaloneFunction(MutableHandleFunction fun, GeneratorKind generatorKind,

Should be |HandleFunction fun|

@@ +74,5 @@
> +    CodeNode* parseStandaloneFunction(MutableHandleFunction fun, GeneratorKind generatorKind,
> +                                      FunctionAsyncKind asyncKind,
> +                                      const Maybe<uint32_t>& parameterListEnd);
> +
> +    bool compileStandaloneFunction(CodeNode* parsedFunction, MutableHandleFunction fun);

I'd generally prefer the MutableHandleFunction to be the first argument since it is the partially initialized subject. In this current form it looks like an out param in our style rather than an in-out. That being said, this isn't worth rebasing over.
Attachment #9021000 - Flags: review?(tcampbell) → review+
Attachment #9021001 - Flags: review?(tcampbell) → review+
Attachment #9021002 - Flags: review?(tcampbell) → review-
Attachment #9021003 - Flags: review?(tcampbell) → review+
Attachment #9021004 - Flags: review?(tcampbell) → review+
Attachment #9021005 - Flags: review?(tcampbell) → review+
Comment on attachment 9021002 [details] [diff] [review]
Define BytecodeCompiler::sourceObjectPtr() inline, closer to the top of BytecodeCompiler's definition

Review of attachment 9021002 [details] [diff] [review]:
-----------------------------------------------------------------

uhh.. drop-down menus are hard, okay?
Attachment #9021002 - Flags: review- → review+
Comment on attachment 9021006 [details] [diff] [review]
Create a BytecodeCompiler subclass to perform module compilation

Review of attachment 9021006 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/frontend/BytecodeCompiler.cpp
@@ +462,2 @@
>  {
> +    if (!createSourceAndParser(ParseGoal::Module) || !createCompleteScript()) {

It would be nice to common this up with prepareScriptParse for consistency. Even at the end of the patch stack there seems to be inconsistency in which parse entry points use prepare/parse/compile.
Attachment #9021006 - Flags: review?(tcampbell) → review+
Comment on attachment 9021007 [details] [diff] [review]
Create a BytecodeCompiler subclass for standalone function compilation

Review of attachment 9021007 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/frontend/BytecodeCompiler.cpp
@@ +189,5 @@
> +      : BytecodeCompiler(cx, alloc, options, sourceBuffer)
> +    {}
> +
> +    MOZ_MUST_USE bool prepare(const Maybe<uint32_t>& parameterListEnd) {
> +        return createSourceAndParser(ParseGoal::Script, parameterListEnd);

Might be worth a having a comment to say that createScript is called in SFBC::compile.

In follow-up work it would be nice if we could make StandaloneFunction and GlobalScript/EvalScript agree on script handling for the asm.js case. This one seems to avoid allocating the JSScript, but the EvalScript case always allocates the JSScript.
Attachment #9021007 - Flags: review?(tcampbell) → review+
Attachment #9021008 - Flags: review?(tcampbell) → review+
Comment on attachment 9021009 [details] [diff] [review]
Separate source-unit-aware functionality out of BytecodeCompiler into unrelated subclasses so that unit-agnostic functionality can be shared

Review of attachment 9021009 [details] [diff] [review]:
-----------------------------------------------------------------

Okay, put the jigsaw puzzle together and didn't end up with any missing pieces.

The rebased version on https://hg.mozilla.org/try/rev/fc2825851782 also is r+.

::: js/src/frontend/BytecodeCompiler.cpp
@@ +154,5 @@
>      // This assumes the created script's offsets in the source used to parse it
>      // are the same as are used to compute its Function.prototype.toString()
>      // value.
> +    MOZ_MUST_USE bool createCompleteScript(BytecodeCompiler& info) {
> +        uint32_t len = sourceBuffer_.length();

s/len/toStringEnd/ to make the comment above super clear.

@@ +155,5 @@
>      // are the same as are used to compute its Function.prototype.toString()
>      // value.
> +    MOZ_MUST_USE bool createCompleteScript(BytecodeCompiler& info) {
> +        uint32_t len = sourceBuffer_.length();
> +        return info.internalCreateScript(0, len, len);

/* toStringStart = */ 0

@@ -255,3 @@
>  
>  BytecodeCompiler::BytecodeCompiler(JSContext* cx,
>                                     LifoAlloc& alloc,

I removed this in m-c to cleanup some mess, but now that SourceAwareCompiler exists it might be nice to put the alloc ref there (so that it matches Maybe<Parser> lifetime). Then we could properly have all the FooCompiler instances get passed a LifoAllocScope&. (The LifoAllocScope would be in code instead of wrapped in FooCompiler because I've found embedding LifoAllocScope in structs is asking for trouble).

Anyways, any of this would be after this whole series sticks first.
Attachment #9021009 - Flags: review?(tcampbell) → review+
Comment on attachment 9021010 [details] [diff] [review]
Templatize everything that's source-aware in bytecode compilation

Review of attachment 9021010 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for splitting off this patch.
Attachment #9021010 - Flags: review?(tcampbell) → review+
(Assignee)

Comment 41

5 months ago
Previous patch had a simple stupid bug pointed out in it when I could actually exercise this.
Attachment #9024142 - Flags: review?(tcampbell)
(Assignee)

Updated

5 months ago
Attachment #9021028 - Attachment is obsolete: true
Attachment #9021028 - Flags: review?(tcampbell)
(Assignee)

Updated

5 months ago
Blocks: 1504463

Comment 42

5 months ago
Pushed by jwalden@mit.edu:
https://hg.mozilla.org/integration/mozilla-inbound/rev/958a348c9ee0
Remove obsolete "|options.utf8| must be set" comments from UTF-8 compilation function docs.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/15d7f3fb96d5
When compiling a module script, create the ModuleObject after creating the script for it.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/e6b6326c593d
Compute script start position after creating the script proper, in BC::compileScript.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/2052c58dfe98
Move module-compilation's createSourceAndParser call into a separate prepareModuleParse function, anticipating when only that function will have to deal with multiple kinds of SourceBufferHolder.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/d9e71df3d1d7
Move script-compilation's createSourceAndParser call into a separate prepareScriptParse function, anticipating when only that function will have to deal with multiple kinds of SourceBufferHolder.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac6aea751ee9
Move standalone function-compilation's createSourceAndParser call into a separate prepareStandaloneFunctionParse function, anticipating when that function will have to deal with multiple kinds of SourceBufferHolder.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/37b4694f5fcf
Move script creation into prepareScriptParse.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/b0c005ef9cee
Move script creation into prepareModuleParse.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/2792e47984ee
Rename BytecodeCompiler::createScript() to BytecodeCompiler::createCompleteScript().  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/1737079f61dd
Split BytecodeCompiler::compileStandaloneFunction into BytecodeCompiler::{parse,compile}StandaloneFunction.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/49b72ccc9682
Move BytecodeCompiler's members to the top of the class definition.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/0db3c534950c
Define BytecodeCompiler::sourceObjectPtr() inline, closer to the top of BytecodeCompiler's definition.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/17243a560006
Remove BytecodeCompiler::enclosingScope and just make users provide it themselves when they need it.  r=tcampbell
(Assignee)

Comment 43

5 months ago
A number of the patches here can be disentangled from dependency on bug 1503086 -- landed those.  Patches after that point start not applying cleanly upon |hg qpu --move|; I think I could fix some of that, but I run out of runway at some point, and I keep hoping that patch will get reviewed soon enough to not be worth the hassle.

So, land some now, leave-open for the rest (including the ones still outstanding).
Keywords: leave-open
Comment on attachment 9021013 [details] [diff] [review]
Implement CompileGlobalScript in terms of a template CreateGlobalScript function that handles UTF-8 and UTF-16 both

Review of attachment 9021013 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/frontend/BytecodeCompiler.cpp
@@ +266,5 @@
> +    explicit ScriptCompiler(SourceText<Unit>& srcBuf)
> +      : Base(srcBuf)
> +    {}
> +
> +    MOZ_MUST_USE bool prepareScriptParse(BytecodeCompiler& compiler) {

(Optional) This is probably a unnecessary redefinition.
Attachment #9021013 - Flags: review?(tcampbell) → review+
Attachment #9021016 - Flags: review?(tcampbell) → review+
Attachment #9021020 - Flags: review?(tcampbell) → review+
Attachment #9021029 - Flags: review?(tcampbell) → review+
Comment on attachment 9021031 [details] [diff] [review]
Introduce a new BytecodeCompilation.h header for fresh bytecode compilation signatures coming soon

Review of attachment 9021031 [details] [diff] [review]:
-----------------------------------------------------------------

Sum of result files seems to correspond to original file and spot-checks all looked good.
Attachment #9021031 - Flags: review?(tcampbell) → review+
Comment on attachment 9021032 [details] [diff] [review]
Remove the original CompileGlobalScript overload, and rewrite all users to use the new (GlobalScriptInfo&, SourceText<char16_t>&, ScriptSourceObject**) overload

Review of attachment 9021032 [details] [diff] [review]:
-----------------------------------------------------------------

\o/
Attachment #9021032 - Flags: review?(tcampbell) → review+
Attachment #9021033 - Flags: review?(tcampbell) → review+
Attachment #9021034 - Flags: review?(tcampbell) → review+
Comment on attachment 9024142 [details] [diff] [review]
Implement ScriptSource::appendSubstring for UTF-8 source text, using a newly-implemented StringBuffer::append(const Utf8Unit* units, size_t len)

Review of attachment 9024142 [details] [diff] [review]:
-----------------------------------------------------------------

Looks reasonable. I'm assuming any weirdness about start/end would have been addressed in the column number fixes bug so I did not stare too hard at the pre-existing code for that.

::: js/src/vm/CharacterEncoding.cpp
@@ +631,5 @@
> +
> +            ++units;
> +            --len;
> +        }
> +        if (len == 0) {

Need a comment after this.

// Encountered non-ASCII text so inflate this StringBuffer and continue converting remaining characters.
Attachment #9024142 - Flags: review?(tcampbell) → review+

Comment 49

5 months ago
Pushed by jwalden@mit.edu:
https://hg.mozilla.org/integration/mozilla-inbound/rev/43b8810bb3ed
Create a BytecodeCompiler subclass to perform global script compilation.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/76feab5328ed
Create a BytecodeCompiler subclass to perform eval script compilation.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/3ed7e8a37562
Create a BytecodeCompiler subclass to perform module compilation.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/9dc874d79c1f
Create a BytecodeCompiler subclass for standalone function compilation.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/630a16450066
Adjust some access controls now that BytecodeCompiler is used only as base class, not on its own.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/532b05c76fa0
Separate source-unit-aware functionality out of BytecodeCompiler into unrelated subclasses so that unit-agnostic functionality can be shared.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/422924c19ce5
Templatize everything that's source-aware in bytecode compilation.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d7d25507cac
Implement CompileGlobalScript in terms of a template CreateGlobalScript function that handles UTF-8 and UTF-16 both.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/ecf813f9f9ea
Implement ScriptSource::setSourceCopy to work for both UTF-8 and UTF-16 source text.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/ba4bdabbdd52
Create syntax and full parsers in bytecode compilation passing |SourceText::units()|, so that Utf8Unit appearing here will continue to require individualized treatment.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/774a0684f724
Implement ScriptSource::appendSubstring for UTF-8 source text, using a newly-implemented StringBuffer::append(const Utf8Unit* units, size_t len).  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/ba6ba95b3cd2
Add a UTF-8 parser to the Variant inside EitherParser.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/1dd5267839b3
Introduce a new BytecodeCompilation.h header for fresh bytecode compilation signatures coming soon.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/24670a08843e
Remove the original CompileGlobalScript overload, and rewrite all users to use the new (GlobalScriptInfo&, SourceText<char16_t>&, ScriptSourceObject**) overload.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d9b2d6342f7
Remove the original CompileEvalScript overload, and rewrite all users to use a new (EvalScriptInfo&, SourceText<char16_t>&) overload that calls a UTF-8/16-ready template function.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/a005d87f9e92
Convert the two CompileModule functions to template functions, then call them inside non-template overloads.  r=tcampbell
https://hg.mozilla.org/integration/mozilla-inbound/rev/280587e10c97
Make StandaloneFunctionCompiler::parse's |MutableHandleFunction fun| argument merely a |HandleFunction|, and make the compile function take its |MutableHandleFunction| argument first, not last.  r=tcampbell as part of prior review comments
(Assignee)

Updated

5 months ago
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.