here is the new method you can call into directly to get QI from either the VB or C# semantic QI provider.

I don't have you going through teh service, because the service is the thing that implies you are tied to a workspace, and we ahve providers that deeply assume they are in a real workspace (for example, teh provider that gives diagnostic information in QI). It sounds like for lsif we dont' want that view, and we only want the view of what we can get purely with a semantic model. so that's what this API provides.

The core issue here is now all the code in QuickInfoServiceWithProviders.cs needs to be duplicated in LSIF generator or knowledge about two kinds of contexts needs to be added to QuickInfoServiceWithProviders to avoid code duplication. I don't like the former as it makes the code harder to maintain, and the latter is basically the same kind of refactoring that I have in my PR. Let me see if there is a good middle ground I can find to get your preferred API shape, while avoiding code duplication.

This API also needs to move further up the type hierarchy into CommonQuickInfoProvider, otherwise we miss getting quick info from other providers that derive from it: https://sourceroslyn.io/#Microsoft.CodeAnalysis.Features/QuickInfo/CommonQuickInfoProvider.cs,8b30b4e85a5560e4,references. This in turn means these other providers deriving from CommonQuickInfoProvider also need two implementations now - one which work on QuickInfoContext and other which work on CommonQuickInfoContext. It feels it will just get messier.

@CyrusNajmabadi I pushed 2 commits to your branch:

1. First commit: Moves the semantic model based Get QI API to CommonQuickInfoProvider
2. Second commit: Adds a semantic model based Get QI entry point to QuickInfoServiceWithProviders. This API can directly be invoked from LSIF generator now.

I personally prefer the 2 parallel set of types approach that I took in my PR (QuickInfoProvider/QuickInfoContext for external vs InternalQuickInfoProvider/InternalQuickInfoContext) over parallel APIs that need to be implemented all the way down the type chain, but I don't have strong feelings, so I am happy to sign off on this PR.

This API also needs to move further up the type hierarchy into CommonQuick

This was intentional. I didn't think tjeh other providers make sense. I didn't think we wanted diagnostic information here. I also dont' think we can even support diagnostic information given that this runs on a workspace that will not have a real diagnostic service.

Also, the syntactic quick info didn't seem like something we wqanted. However, if we did, i would pull a common base type up above the Syntactic/Semantic providers.

Oh okay - in that case feel free to revert my commit.

Oh, actually, the way you did this is fine. You just didn't support this functionality with the diag provider. I think that's 100% ok. I thought you wanted it at the root and wanted to support diags :) I'm ok keeping your code. I just need to see why integration tests are failing.

note: this is just used to retrieve language services. it coudl be weakened to that type if desired.