in_file.py should be able to parse "in" files

in_file.py should be able to parse "in" files

The in_file.py parser was missing support for parameters, like "namespace",
which are common in "in" files.

R=eseidel@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=149474

[eseidel, 2013-04-30 21:46:16]

lgtm

Fragile.  But OK.

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file.py
File Source/core/scripts/in_file.py (right):

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file.p...
Source/core/scripts/in_file.py:77: if not line:
So a leading newline (between the comments and the parameters) will confuse
this.  This seems bad.

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file.p...
Source/core/scripts/in_file.py:89: name, value = line, True
If we don't support bare parameters, then parameter parsing is probably easier
as they always have a =, no?

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file_u...
File Source/core/scripts/in_file_unittest.py (right):

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file_u...
Source/core/scripts/in_file_unittest.py:53: contents =
"""namespace=TestNamespace
Yes, requiring no leading newline is making your tests awkward too. :)  I could
imagine wanting to have something like this:

# This is an awesome file

# Needed to make foo work
foo=bar
 
#neded for bar
bar=baz

here
we
go
now

We obviously don't need to support this on day one.

[abarth-chromium, 2013-04-30 21:50:44]

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file.py
File Source/core/scripts/in_file.py (right):

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file.p...
Source/core/scripts/in_file.py:77: if not line:
On 2013/04/30 21:46:16, Eric Seidel (Google) wrote:
> So a leading newline (between the comments and the parameters) will confuse
> this.  This seems bad.

I'm just matching the behavior of the Perl "in" file parser.  Once we delete the
Perl parser, we should definitely consider evolving the syntax to be less
brittle.

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file.p...
Source/core/scripts/in_file.py:89: name, value = line, True
On 2013/04/30 21:46:16, Eric Seidel (Google) wrote:
> If we don't support bare parameters, then parameter parsing is probably easier
> as they always have a =, no?

The Perl supports parameters that lack a =.  I don't know if we ever use this
feature.

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file_u...
File Source/core/scripts/in_file_unittest.py (right):

https://codereview.chromium.org/14696003/diff/1/Source/core/scripts/in_file_u...
Source/core/scripts/in_file_unittest.py:53: contents =
"""namespace=TestNamespace
On 2013/04/30 21:46:16, Eric Seidel (Google) wrote:
> Yes, requiring no leading newline is making your tests awkward too. :)  I
could
> imagine wanting to have something like this:
> 
> # This is an awesome file
> 
> # Needed to make foo work
> foo=bar
>  
> #neded for bar
> bar=baz
> 
> here
> we
> go
> now
> 
> We obviously don't need to support this on day one.

Actually, it looks like the Perl support leading blank lines before switching
into parameter mode.  It doesn't support interspersed blank lines, however. 
I'll update the Python to better match the Perl.

After we remove the Perl, I agree that we'll want to improve the syntax of these
files.

[abarth-chromium, 2013-04-30 21:58:15]

Turns out I can't make the Python match the Perl in this case because it causes
RuntimeEnabledFeatures.in not to parse.  I'm going to land this CL as-is as
discussed in person.

[abarth-chromium, 2013-04-30 22:01:35]

Committed patchset #1 manually as r149474 (presubmit successful).