i am wildly curious why SyntaxClassification is using semantic models at all...................................................

Yeah, I do not have enough thumbs to thumbs-up @CyrusNajmabadi's comment here.

Oh, or is this just confusing naming? This "syntax classification service" is doing both actual syntax classification and also semantic classification?

oh right. it's 'Syntax' in that it's C#/VB classification, not for other languages. bleaghhhhhhhhh why is my naming so bad.

Yes, this type handles each of the various types of classification. This change is on the semantic classification path.

@sharwell: ah, interesting. It would seem this should be either:

1. Freezing on the OOP side then when that service is called before it makes it here.
2. Somehow passing the frozen state across.

The latter is a strange concept in this case: even if you ignore source generators for a moment, the idea of frozen semantics is you are getting a compilation and snapshot that doesn't require any further effort to produce a Compilation. But if we remote that frozen snapshot over, we'll potentially have to spend more time syncing that snapshot on the OOP side than if we simply froze whatever OOP had in the first place.

Unless there was a reason to not freeze? @CyrusNajmabadi?

Converted to draft. I believe this needs to be rewritten with the following characteristics:

1. OOP needs to use frozen partial semantics when in-process does
2. OOP may use the same solution data from in-process, but the only hard requirement is we need to make sure that if the in-process solution was frozen with a specific document guaranteed, that document also exists in the frozen OOP solution

Given the weird timing approach for frozen partial semantics in process, I don't believe it's critical to force an exact match of all frozen state when making an OOP call. It's arguably more correct, but doesn't seem likely to produce visible discrepancies if/when we deviate.

How does LSP communicate that the semantics are stale and they can be refreshed?

Currently this happens via polling in VS, though there are some ongoing discussions on if we want to switch to the workspace/semanticTokens/refresh event

Yeah, so "frozen" isn't really a persisted concept in the way that we can remote it to OOP and then have that follow a different set of semantics. If the in-proc and out-of-proc don't require the exact same semantics, then there's no reason to get fancy here: just have the out-of-proc service call the method to freeze before doing the rest of the work. Easy.

note: i'm always worried about oop/in-proc being out of sync. but i agree if we're very careful (And at least ensure the doc we're callign on is in sync) it's likely to be a non-issue for classification.

however, we have other features using frozen-partial, where i think not-being in total sync could be a big issue. for example, nav bars use frozen partial and have results that refer to other documents. So if we did frozen-partial on both ends, but somehow were in disagreement with things like positions and wahtnot, we could have a potential race/crash.