Open Bug 1567464 Opened 9 months ago Updated 8 months ago

Display type for variable


(Webtools :: Searchfox, enhancement)

Not set


(Not tracked)



(Reporter: calixte, Assigned: asuth)



(1 file)

Sometimes it's uneasy to guess what's the variable type (especially when defined with auto keyword or when the variable is used far from its definition).
Maybe it'd be interesting too to have the function prototype on function calls.

I have some local changes that add "type" (just a string) and "typesym" (if we could get a TagDecl out of the type that we could then mangle) to source analysis records produced by the clang indexer.

Assignee: nobody → bugmail

I've got some type information for C++ locals being displayed up at When you click on a token with associated symbol data (as in, hovering it causes other instances of that symbol to be highlighted), the menu that pops up should have the type in the header. The header is basically "syntaxKind typeFromClang symbolName".


  • This includes UI changes that include speculative loading of background searches which may jank things the first time you mouse passes over a RefPtr because we don't cap the search results on that yet. The searches are cached so it shouldn't be too bad.
  • I seem to have (temporarily) broken the "define" URL endpoint. I'll fix that later today and it should magically start working again.
  • I may have over-normalized the type info by bouncing it through a unifying dictionary. I can expand that back out to just a "data-type" attribute to avoid loss of info there. I'll try and run an assertion-checking indexing pass.
  • It seems like clang QualTypes may sometimes actually claim a type of "auto" when auto is used. Some more type-piercing may be necessary in the indexer for that special case.
Attached image screenshot on mobile

I'll try when I'm at a laptop but this is what it looks like on mobile... The popup thingy is cut off so I can't see the whole thing.

I have to concede I have rarely used searchfox on a mobile phone form-factor. I expect the mega-menu needs to fall back to disabling the sub-pane when there's insufficient screen real-estate. It already runs into trouble on narrow displays/windows when the token being clicked on is on the right side of the window.

It may also beg the question as to whether searchfox should use a more finger-friendly full-screen-ish modal-ish menu styling for mobile/touch use.

Search/define should work on now. Note that speculative fixes for bug 1511025 are also included which is expected to alter redundant over-specific template instantiations, but could have side-effects. And I didn't address over-consolidation of types, so that may still be there.

You need to log in before you can comment on or make changes to this bug.