You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix Code Lens around source generated files (#79992)
To best understand this fix, we first need to discuss how CodeLens works
in Visual Studio. The editor calls our implementation of
IAsyncCodeLensDataPointProvider which exists in a ServiceHub process
created for CodeLens which is not our usual ServiceHub process. That
implementation uses the callback feature to marshal a call back to
devenv, where from there we then do an OOP operation to our ServiceHub
process via the usual mechanism. This is where we compute the actual
results, which then get marshalled back to devenv and then back to the
CodeLens ServiceHub process, where we finally send the data via the
CodeLens APIs.
The core type of this is a ReferenceLocationDescriptor which represented
a reference location in a specific location in a document. However,
because this struct returned from our ServiceHub to devenv, and then
from devenv to the CodeLens service hub, it needs to be serialized and
deserialized twice. The serialization channels are different though, so
whereas a DocumentId can serialize between devenv and our ServiceHub
process, it would get tripped up when it serializes between devenv and
the CodeLens ServiceHub process. Because of this, the type instead
decomposed a DocumentId into the GUIDs and manually
serialized/deserialized it.
This serialization/deserialization was broken once DocumentIds got a "is
source generated" bit, since we'd lose that bit which would break
things. I could have added that bit in and updated the serialization but
the question we hit was "why can't I just pass a DocumentId?" Well, the
answer was because we might try sending that DocumentId to the CodeLens
ServiceHub process, but upon closer inspection, the result of that was
never used. The flow was that we'd take the results with document IDs
out of our ServiceHub process, then do some filtering and mapping for
Razor scenarios (which used those document IDs); at this point the
results don't need document IDs anymore. So to do this I split out the
"mapping" as a separate operation for clarity, and then used different
types, one with the ID and one without, for the different flows.
There is still one bug left here: code lens will now show references in
source generated documents, but you can't open those since we aren't
returning a file path VS will understand there. That's fixable too, but
this is a significant improvement so let's get this done first. I'm not
sure if fixing that might require other code changes in the CodeLens
system...
Fixes#79699Fixes#76608Fixes#74104
/// Maps the list of referenced locations through span mapping services to the final list of locations; locations may be in files that aren't regular documents.
0 commit comments