1416899 - Index WebIDL files

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The idea would be to link definitions in WebIDL files to implementations in C++.

Comment 1

[Andrew McCreight [:mccr8]]

Maybe the WebIDL code generator could be changed to have a special mode where it dumps out info for SearchFox at the same time it is doing code generation. That seems better than doing what IPDL does (a separate parser). I don't know how XPIDL is handled.

Comment 2

[Boris Zbarsky [:bzbarsky]]

We can certainly dump out information somewhere, especially if someone tells me what format and where.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The basic process by which IPDL and XPIDL work is:
1. Wait for the header files generated by the code generator to be compiled by clang. The clang plugin will generated analysis data for these files, including the mangled names of the C++ methods involved.
2. For each IPDL/XPIDL file, find the line and column number of all methods. Figure out what C++ class they're in, and match them up to a mangled name found in (1). This is a little hacky and it only works if these methods have no overloads.
3. Generate data for the IPDL/XPIDL file in the form required by Searchfox. This format is described here:
https://github.com/mozsearch/mozsearch/blob/master/docs/analysis.md

I think we would do the same thing for WebIDL. This is what's needed:
A. For any identifier we need to highlight, the WebIDL filename and the line and column number where the identifier starts.
B. The C++ class and method/field names for all such identifiers.
C. The locations of the header files where those C++ classes are to be found.

With this data, we can read the C++ analysis data for the file in (C) to find the mangled name for the symbol based on the data in (B).

Comment 4

[Boris Zbarsky [:bzbarsky]]

WebIDL-generated things are typically not in classes (generated event impls are the obvious execption).  They're in namespaces.

So if you have this IDL:

  interface Foo {
    readonly attribute long bar;
  };

That generates a .cpp file with:

  namespace mozilla {
  namespace dom {
  namespace FooBinding {
    bool get_foo(args);
  }
  }
  }

The get_foo method is not in any header at all.  In the event class case (and actually in the JS-implemented case), a single webidl declaration generates multiple C++ methods: the binding method and an implementation (two implementations, really, for the JS-implemented case).

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

OK. Namespaces are pretty easy to deal with since the mangling is simple. And having multiple methods is also okay.

(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #4)
> The get_foo method is not in any header at all.  In the event class case
> (and actually in the JS-implemented case), a single webidl declaration
> generates multiple C++ methods: the binding method and an implementation
> (two implementations, really, for the JS-implemented case).

How should the context menu be organized for these cases? Should there be one menu items that searches for all the different kinds of methods and combines the results? Or should there be one menu item per method? Both are possible (although only the latter would allow us to have a "Go to definition" option for each method).

Comment 6

[Boris Zbarsky [:bzbarsky]]

I'm not really sure.  I haven't really missed having this, so I'm not clear on what the use cases are.