Open Bug 1416899 Opened 7 years ago Updated 6 days ago

Index WebIDL files

Categories

(Webtools :: Searchfox, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: billm, Assigned: arai)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

The idea would be to link definitions in WebIDL files to implementations in C++.
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.
We can certainly dump out information somewhere, especially if someone tells me what format and where.
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).
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).
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).
I'm not really sure.  I haven't really missed having this, so I'm not clear on what the use cases are.
See Also: → 1525189
Assignee: nobody → arai.unmht
Status: NEW → ASSIGNED
Depends on: 1901445
Attached file GitHub Pull Request
Attached file GitHub Pull Request
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: