Semantic Search: Add support for async queries and FAR tool

[tmat]

Allows semantic search queries to be async and to call additional pre-defined APIs that provide IDE layer capabilities without referencing Workspace/Feature layer.

Currently the additional APIs are:

public static class Tools
{
    /// <summary>
    /// Returns all syntax nodes that reference a given symbol.
    /// </summary>
    public IEnumerable<SyntaxNode> FindReferencingSyntaxNodes(this ISymbol symbol);

    /// <summary>
    /// Returns semantic model for given syntax tree.
    /// Use to access semantic information from syntax nodes or trees.
    /// </summary>
    public Task<SemanticModel> GetSemanticModelAsync(this SyntaxTree tree);
}

The implementation uses Solution behind the scenes to provide access to FAR and Semantic Model across the whole solution.
It is injected into the generated query assembly via reflection.

[tmat]

@CyrusNajmabadi Quick impl of the FAR tool for semantic search we talked about: ReferencingSymbolsFinder. Borrowed some code from producer-consumer utils to convert callbacks to IAsyncEnumerable. This can likely be generalized into another helper in the utils. We can also refactor IFindUsagesService to accept ISymbol as input so that I don't need to go from ISymbol to location and then back to ISymbol. Might want to add another service that's not ILanguageService, since I do not start with document and don't know the language.

[CyrusNajmabadi]

The implementation uses Solution behind the scenes to provide access to FAR and Semantic Model across the whole solution.

I love this. That said, i think we might want some docs somewhere (and maybe they're already in teh PR) as to how this works and why thsi is safe. Someone on the team may go: "but wait... a SYntaxTree doesn't uniquely map to a SemanticModel!"

We want to explain that all these 'tools' operate at single snapshot point in time and thus these things do work.

[CyrusNajmabadi]

i don't understnad this. why are we returning the enclosing symbol for a found reference?

[CyrusNajmabadi]

nit. indent one more.

[CyrusNajmabadi]

nice.

[CyrusNajmabadi]

who ends up potentially catching if this happens? or should this be impossible as we own the emitting of these assemblies?

[CyrusNajmabadi]

i don't love the naked catch. Why not FatalError report this?

[CyrusNajmabadi]

does .Name do a good job here? i thought with instantiated generics it was something awful :) do you have a test showing what error message we actually get?

personally, it might be better to literally hardcode "IEnumerable<ISymbol>".

--

Oh, looking at this in a console app, you just get IEnumerable`1. That doesn't seem great here. Consider just hard coding the name.

[CyrusNajmabadi]

consider checking CT here. same with foreach loop above.

[CyrusNajmabadi]

super cool.

[CyrusNajmabadi]

so... looking at how this is used, i have an alternate suggestion. instead of returning this isAsync flag, just always return an IAsyncEnumerable. If you get an IEnumerable, then that is trivially wrappable in an IAsyncEnumerable. Which then means all subsequent code operates uniformly.

[CyrusNajmabadi]

yeah, basically here get teh result, and if is an IEnumerable, wrap into an IAsyncEnumerable. And now everything is consistent, and you don't need the flag passed through.

[CyrusNajmabadi]

aside: odd that all the symbols are getting "isPrimary: true". but probably doesn't matter that much.

[CyrusNajmabadi]

nice. i didn't realize they had this.

[CyrusNajmabadi]

Suggested change

	internal sealed class ReferencingSyntaxFinder(Solution solution, OptionsProvider<ClassificationOptions> classificationOptions, CancellationToken cancellationToken)
	internal sealed class ReferencingSyntaxFinder(
	Solution solution,
	OptionsProvider<ClassificationOptions> classificationOptions,
	CancellationToken cancellationToken)

nit: when lines are too long for github, i like that as a good choice to wrap.

[CyrusNajmabadi]

hrmm... this seems wrong. it would mean that someone couldn'lt, for example, find referencing syntax nodes for a metadata symbol.

[CyrusNajmabadi]

i think i prefer FindReferencingSyntaxNodes and FindReferencingSyntaxNodesAsync. how do you feel?

[tmat]

Seems redundant since the containing type is already called ReferencingSyntaxFinder. Maybe just Find :)

[CyrusNajmabadi]

oh true. i was thinking this was the name a user saw.

1. i'm fine with this being called 'Find'
2. i like the name you chose (FindReferencingSyntaxNodes) for what users see.

#resolved.

[CyrusNajmabadi]

ok. this seems like a super strange way to do things :) i get hwat you're doing. you're mapping back from a source symbol to its decl location, so ou can call this here. However, you shouldn't have to IMO. You should be able to literally just call intot his directly

public static partial class SymbolFinder
{
    internal static async Task FindReferencesAsync(
        ISymbol symbol,
        Solution solution,
        IStreamingFindReferencesProgress progress,
        IImmutableSet<Document>? documents,
        FindReferencesSearchOptions options,
        CancellationToken cancellationToken)
    {

And then just have your IStreamingFindReferencesProgress push into a channel. And just return channel.Reader.ReadAllAsync.

It really should be super simple.

[CyrusNajmabadi]

so cool.

Note: we might want to doc that we should consider a caching strategy here. Personally, i think it probably makes sense that for the lifetime of of the entire LLM call that all the models are kept alive. And only dumped at the end.