D19637 doesn't actually improve this, but it brings us a step closer (since the logic is now in PHP and can be modified more easily to label symbols and add context).

The actual support issues were likely addressed or obsoleted by the above changes. The rest of this is still planned, probably won't move forward any time soon.

I think a reasonable path forward here is for Diviner to have a {symbol} sort of syntax which executes a symbol index query. The symbol index can already be configured to know how to offer links to external documentation.

See PHI185. This was fixed by D18753 but didn't get linked up.

Maybe this works now?

Per above, I think the pathway forward here is probably "tighter integration", not "merge/replace", i.e. tools for Diviner to automatically update Symbols, too. I'm just going to conceptually roll this up into T13047.

I think this probably isn't worth fixing in the upstream: different versions of PHP are mostly the same; there's usually a good argument for deploying the same version of PHP everywhere; and Phabricator supports both very old and very modern versions of PHP so it should usually be easy to run Phabricator on whatever version of PHP you're developing against.

I believe this is supported now (and for some time) in the general case in terms of Phabricator infrastructure. Actually getting it to work requires a very smart highlighter, and the upstream XHPAST highlighter is the only one in existence. But other tasks, like T3130, are better homes for parser/AST improvements to particular languages.

To reproduce:

I think this (and lint/coverage) should move to Conduit, yeah.

Thank you so much for giving me help here. Have a nice weekend. @avivey

It's based on git-grep. You can't give it any arguments.

Wow, that's great.

https://secure.phabricator.com/diffusion/P/browse/master/ - there's a Show Search button, that will let you search by filename or file contents.

Thank you so much for the help. Now it works.

Looking at the first image, it looks like the symbols are defined to be cpp symbols; That would fit your description of the behavior:
When searching from the search-field, the system ignores language of the symbols; When looking from a source file, it narrows down the search to files of the same language - in this case I think it should be swift.