On 2015/03/06 07:03:40, rossberg wrote:
On 2015/03/05 20:56:55, Michael Starzinger wrote:
> https://codereview.chromium.org/974213002/diff/1/src/globals.h
> File src/globals.h (right):
>
> https://codereview.chromium.org/974213002/diff/1/src/globals.h#newcode457
> src/globals.h:457: enum ParseRestriction {
> On 2015/03/05 20:18:30, titzer wrote:
> > On 2015/03/04 10:25:12, rossberg wrote:
> > > I don't think this belongs into global.h - it encodes a choice of start
> symbol
> > > for parsing. In that sense, it has a similar role to flags like
> > > parse_info->is_module(), and should probably be handled analogously.
I.e.,
> > just
> > > kill the enum and have a is_function flag in parse info. (And later we
> should
> > > probably unify these flags into one grammar_entry kind of value.)
> > >
> > > Short of that, can you at least move it to parser.h?
> >
> > Michi argued strongly to keep the enum.
> >
> > I initially tried to move it to parser.h, but then you end up with a cycle > > between compiler.h and parser.h. Actually this cycle already exists and it
> needs
> > to be broken carefully to reduce the over-inclusion of compiler.h.
Couldn't
> > figure out how to do that yet.
>
> I argued strongly for "not turning it into a boolean", correct. I would be
fine
> with the parser just reporting whether it consumed exactly one single
function
> literal or not, and then the caller checking that result. That would be fine
> with me. FYI, the caller is all the way up in Runtime_CompileString.

Hm, that would seem backwards to me. This is really about what grammar start
symbol to enter parsing with.

For modules we have the same problem, and the caller does set_is_module on the
parseinfo. Would you be opposed to have an analogous is_function to set?
(Ideally, one combined enum instead of separate flags, but that'd be for
another
clean-up.)

I am fine with that (both a separate is_function flag, or a combined enum) as
long as it doesn't lead to a random stray boolean in the signature of
Compiler::GetFunctionFromEval.

https://codereview.chromium.org/974213002/

--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to