1859884 - Improve IPDL preprocessing support

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

In bug 1417586 I landed a pragmatic hack where we just ignore preprocessing directives and hope that the result of parsing that will work out okay. Especially since searchfox's IPDL processing does not do anything with types, this works out okay, but there will especially be problems if we try and process data structures.

The least hacky solution is probably to implement bug 1661067 and move to using the in-tree code-generator to generate inherently per-platform analysis data. Searchfox's structured records have a mechanism for understanding data structures varying per-platform, although the binding linkage step in crossref is not platform-variation aware, but it could be[1]. I'm assuming the preprocessor transform leaves positions intact; if it doesn't, it would need to be enhanced.

That said, there potentially exists more that can be done with the current rust-based IPDL processing pipeline, so this bug exists to track that and be referenced by a comment in the source code.

Here's a particularly notable example of the type SystemFontListEntry varying across 3 platforms:

// SetXPCOMProcessAttributes passes an array of font data to the child,
// but each platform needs different details so we have platform-specific
// versions of the SystemFontListEntry type:
#if defined(ANDROID)
// Used on Android to pass the list of fonts on the device
// to the child process
struct SystemFontListEntry {
    nsCString familyName;
    nsCString faceName;
    nsCString filepath;
    uint32_t  weightRange;
    uint32_t  stretchRange;
    uint32_t  styleRange;
    uint8_t   index;
    FontVisibility visibility;
};
#elif defined(XP_MACOSX)
// Used on Mac OS X to pass the list of font families (not faces)
// from chrome to content processes.
// The entryType field distinguishes several types of font family
// record; see gfxMacPlatformFontList.h for values and meaning.
struct SystemFontListEntry {
    nsCString familyName;
    FontVisibility visibility;
    uint8_t   entryType;
};
#else
// Used on Linux to pass list of font patterns from chrome to content.
// (Unused on Windows, but there needs to be a definition of the type.)
struct SystemFontListEntry {
    nsCString pattern;
    bool      appFontFamily;
};
#endif

1: That said, I'm not sure making it per-platform-aware is necessarily worth the effort. Given the introduction of "labels" on symbols which translate into "badges" for presentation purposes, it might just be enough to automatically mark SystemFontListEntry and any other IDL symbols which vary across platforms as "it's complicated" with a shrugging human emoji which conveys that searchfox's handling of the structure is subpar.