Refactor IDL value checking into SemanticAnalyzer.pm

Refactor IDL value checking into SemanticAnalyzer.pm

This is minor refactoring; it makes the main generate-bindings.pl file
smaller (by putting the semantic analysis phase into a library), which
makes it easier to rewrite in Python, since these can be done incrementally.

I've made the refactored functions object-oriented, which is more natural
(loads a file on initialization), and will make it clearer when porting
to Python.

BUG=239771

[Nils Barth (inactive), 2013-06-03 05:27:10]

Hi haraken,
A little refactoring, moving a big chunk of independent functionality into a
library; this makes generate-bindings.pl smaller and more modular, which'll help
with the rewrite.
This is basically breaking up
http://crrev.com/15959019
into incremental changes, starting on the Perl side.

This doesn't depend on the JSON;
it means there's less in the main script though, which
makes it easier to pipe the JSON in and out.

[haraken, 2013-06-03 07:09:17]

I don't know how helpful this change is, but it looks harmless.

https://codereview.chromium.org/15984007/diff/3001/Source/bindings/scripts/ge...
File Source/bindings/scripts/generate-bindings.pl (right):

https://codereview.chromium.org/15984007/diff/3001/Source/bindings/scripts/ge...
Source/bindings/scripts/generate-bindings.pl:1: #!/usr/bin/perl -w
-I../../core/scripts

Nit: I don't think this is needed. If we need to add it, we should handle it in
GYP files.

[haraken, 2013-06-03 07:09:23]

LGTM

[Nils Barth (inactive), 2013-06-03 07:51:01]

On 2013/06/03 07:09:17, haraken wrote:
> I don't know how helpful this change is, but it looks harmless.

This one is pretty small, but it slims the main file down.
The next CL is more substantial, and makes the flow much simpler.

>
https://codereview.chromium.org/15984007/diff/3001/Source/bindings/scripts/ge...
> Source/bindings/scripts/generate-bindings.pl:1: #!/usr/bin/perl -w
> -I../../core/scripts
> 
> Nit: I don't think this is needed. If we need to add it, we should handle it
in
> GYP files.

I did add it to the GYP file in http://crrev.com/16296004 but it's also needed
here; it's a bugfix.

The -I is needed to make the #! line work -- without it, the script is
executable but immediately crashes with "Can't locate preprocessor.pm in @INC".

Without the #! you need to write:
  perl -I../../core/scripts generate-bindings.pl ...
With the #! and -I you can write:
  ./generate-bindings.pl ...

It gets worse with JSON:
  perl -I../../core/scripts -I../../../JSON/out/lib/perl5 generate-bindings.pl
...
vs.:
  ./generate-bindings.pl ...

In derived_sources.gyp and in run-bindings-script (rather,
webkitpy/bindings/main.py) we call Perl directly, so the -I is included there,
but including it in the #! line:
1. makes the script directly executable (useful for debugging)
2. documents the dependencies directly, rather than in a different file -- thus
anyone using the file can see the dependencies.

[commit-bot: I haz the power, 2013-06-03 07:51:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/nbarth@chromium.org/15984007/5001

[haraken, 2013-06-03 08:00:02]

On 2013/06/03 07:51:01, Nils Barth wrote:
> On 2013/06/03 07:09:17, haraken wrote:
> > I don't know how helpful this change is, but it looks harmless.
> 
> This one is pretty small, but it slims the main file down.
> The next CL is more substantial, and makes the flow much simpler.

What will be the substantial change? As I commented in
https://codereview.chromium.org/16296004/, I don't fully understand why we need
to make changes to generate-bindings.pl, which is going to be removed. I'd like
to know your plan.


> The -I is needed to make the #! line work -- without it, the script is
> executable but immediately crashes with "Can't locate preprocessor.pm in
@INC".
> 
> Without the #! you need to write:
>   perl -I../../core/scripts generate-bindings.pl ...
> With the #! and -I you can write:
>   ./generate-bindings.pl ...
> 
> It gets worse with JSON:
>   perl -I../../core/scripts -I../../../JSON/out/lib/perl5 generate-bindings.pl
> ...
> vs.:
>   ./generate-bindings.pl ...
> 
> In derived_sources.gyp and in run-bindings-script (rather,
> webkitpy/bindings/main.py) we call Perl directly, so the -I is included there,
> but including it in the #! line:
> 1. makes the script directly executable (useful for debugging)
> 2. documents the dependencies directly, rather than in a different file --
thus
> anyone using the file can see the dependencies.

I don't quite like the change. Basically we want to centralize the path handling
to GYP files. Directly written relative paths make it hard to move files.
Actually it has broken things when we moved files when we forked WebKit.

[Nils Barth (inactive), 2013-06-03 09:15:45]

On 2013/06/03 08:00:02, haraken wrote:
> On 2013/06/03 07:51:01, Nils Barth wrote:
> > On 2013/06/03 07:09:17, haraken wrote:
> > > I don't know how helpful this change is, but it looks harmless.
> > 
> > This one is pretty small, but it slims the main file down.

> > The next CL is more substantial, and makes the flow much simpler.
> What will be the substantial change?

Issue 15979013: Refactor partial interface resolving and merging into
InterfaceMerger.pm
https://codereview.chromium.org/15979013/
This is also just refactoring, but it's moving blocks out of the main body,
instead of just putting already factored functions into a library,
so it makes the flow clearer.

> As I commented in https://codereview.chromium.org/16296004/, I don't fully
> understand why we need to make changes to generate-bindings.pl, which is going
> to be removed. I'd like to know your plan.

Understood and answered over there; this is to make it easier to land the
changes
incrementally, as the full rewrite is too long to review.


> I don't quite like the change. Basically we want to centralize the path
handling
> to GYP files. Directly written relative paths make it hard to move files.
> Actually it has broken things when we moved files when we forked WebKit.

I don't like manual includes either, but they're needed anytime we use a library
in a different directory in Perl.
(This'll go away in Python.)

We already have it 2 places, namely derived_sources.gyp and
webkitpy/bindings/main.py,
and you're quite right, it's fragile, and the current script is broken.

Actually, can we just move preprocessor.pm to this directory?
It doesn't look like anything else uses it.
I'll try it out and post a different CL.

[commit-bot: I haz the power, 2013-06-03 09:25:24]

Retried try job too often on win_layout_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_layout...

[Nils Barth (inactive), 2013-06-03 09:27:18]

On 2013/06/03 09:15:45, Nils Barth wrote:
> Actually, can we just move preprocessor.pm to this directory?
> It doesn't look like anything else uses it.
> I'll try it out and post a different CL.

Turns out two other files use preprocessor.pm:
core/css/make-css-file-arrays.pl
core/css/makegrammar.pl
...so we can't just move it.

We could just copy it (as it's short), but anyway this is going away so it's not
worth worrying about.

[haraken, 2013-06-03 09:29:21]

Let's wait for landing the CL. I'll post a comment on
https://codereview.chromium.org/16296004/

[commit-bot: I haz the power, 2013-06-04 02:15:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/nbarth@chromium.org/15984007/5001

[Nils Barth (inactive), 2013-06-04 02:17:14]

On 2013/06/03 09:29:21, haraken wrote:
> Let's wait for landing the CL. I'll post a comment on
> https://codereview.chromium.org/16296004/

Oops, restarted CQ before seeing this comment.