1900830 - Make the types in the field-layout display into links (to their field-layout)

Status: RESOLVED FIXED

(Webtools :: Searchfox, enhancement)

Description

[Steve Fink [:sfink] [:s:]]

I showed the new field-layout to jonco, who immediately tried using it for GCRuntime and his first thought was that he was trying to work out why the systemZone field is 16 bytes. If those types were themselves links, he could have just clicked on it. (Note also that there are multiple types for the field, because the template type parameter can be either enum AllowedHelperThread::None or js::AllowedHelperThread::None. We may be at the mercy of clang for that?)

Comment 1

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

We do have the somewhat normalized typesym available, "T_js::ProtectedDataNoCheckArgs" in this case (search), which currently has no clue about the parameters because templates are complicated.

win64 platform field from clicking on the GCRuntime symbol in any searchfox window and bringing up devtools and doing CLICKED_SYMBOLS[0].meta.fields[1] (where we know win64 from CLICKED_SYMBOLS[0].meta).

{
  "pretty": "js::gc::GCRuntime::systemZone",
  "sym": "F_<T_js::gc::GCRuntime>_systemZone",
  "type": "class js::ProtectedDataNoCheckArgs<class js::CheckMainThread<js::AllowedHelperThread::None>, class JS::Zone *>",
  "typesym": "T_js::ProtectedDataNoCheckArgs",
  "offsetBytes": 8,
  "bitPositions": null,
  "sizeBytes": 16,
  "pointerInfo": [
    {
      "kind": "contains",
      "sym": "T_js::ProtectedDataNoCheckArgs"
    }
  ]
}

Note that we don't have the typesym directly available on the field which is a weird asymmetry but one that seemed reasonable at the time; ex, clicking on systemZone and doing CLICKED_SYMBOLS[0].meta in devtools gets us.

{
  "structured": 1,
  "pretty": "js::gc::GCRuntime::systemZone",
  "sym": "F_<T_js::gc::GCRuntime>_systemZone",
  "type_pretty": null,
  "kind": "field",
  "subsystem": "Core/JavaScript/GC",
  "parentsym": "T_js::gc::GCRuntime",
  "implKind": "",
  "sizeBytes": null,
  "bindingSlots": [],
  "ontologySlots": [],
  "supers": [],
  "methods": [],
  "fields": [],
  "overrides": [],
  "props": []
}

Note that the crossref_converter helpers don't automatically make the typesym available in SYM_INFO right now for the field (although that could be reasonable if we started surfacing that in the UI, as was my original intent in introducing type/typesym) both because we don't use it, but also because above, the field doesn't know it. (And it does not make sense to automatically include all fields/methods whenever we see a class type.)

Of course, for this bug, we can presumably just add the symbol to the list of relevant symbols to emit for SYM_INFO.

Comment 2

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

Ah, I just looked at the type instead of skimming it and I should mention that we do have the pointerInfo mechanism here that, when present, should likely supersede the typesym. It is a hack, but the idea is basically that we can mark certain types as "this is just wrapping the thing I really want, keep looking through the parameter args by doing really sketchy parsing stuff". Ex, we have decorator types like DataMutex defined in ontology-mapping.toml. The parsing stuff should be superseded by dumping a higher quality representation from clang, but it currently works and has some tests so it could be worse.

So like for this mTextureClientRecycler thing we get a pointerInfo of TextureClientRecycleAllocator as the type.

DataMutex<RefPtr<TextureClientRecycleAllocator>> mTextureClientRecycler;

If we click on its parent and do CLICKED_SYMBOLS[0].meta.fields[3] we get:

{
  "pretty": "mozilla::layers::CompositableClient::mTextureClientRecycler",
  "sym": "F_<T_mozilla::layers::CompositableClient>_mTextureClientRecycler",
  "type": "class mozilla::DataMutexBase<class RefPtr<class mozilla::layers::TextureClientRecycleAllocator>, class mozilla::Mutex>",
  "typesym": "T_mozilla::DataMutexBase",
  "offsetBytes": 32,
  "bitPositions": null,
  "sizeBytes": 88,
  "pointerInfo": [
    {
      "kind": "strong",
      "sym": "T_mozilla::layers::TextureClientRecycleAllocator"
    }
  ]
}

If someone were to add ontology mappings for the JS team's types, the pointerInfo would be useful. This also helps for the class diagrams (which was why it was introduced) which visualizes field relations. Note that there are different ontology types and decorator is really only intended to apply labels which then frequently want to be mapped to inscrutable emojis, whereas some types should just be pierced without exposing the additional semantics.

Comment 3

[Tooru Fujisawa [:arai]]

Attachment: GitHub Pull Request