-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix potential race where we're expecting a moniker to be attached #65732
Conversation
} | ||
else if (symbol.ContainingAssembly.Equals(sourceCompilation.Assembly)) | ||
{ | ||
kind = "export"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does 'export/import' mean here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically when we're indexing a project, we will stick a moniker for symbols we encounter. 'export' means it came from this project (and is visible elsewhere), 'import' means it came from another project. I'm not sure if the rest of the consumers really use this much, but that's the spec at least.
// Attach the moniker vertex for this result set | ||
_ = GetResultIdForSymbol(symbol, "moniker", () => monikerVertex); | ||
} | ||
_ = this.GetMoniker(symbol, _sourceCompilation); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't really understand this, but ok :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this work doesn't seem complex, is it actually bad to do under the lock?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The lock earlier is a pretty high contention lock -- we have to hit it to look up a symbol -> id mapping every time we process any token, so it seems best to keep it out.
This change makes things a bit more robust anyways -- the other place assuming there was a moniker might also be wrong if for some reason we didn't have a moniker for that symbol so there's no real concern about the race anymore.
Ran this changeset locally against WebTools and it worked! /cc @jimmylewis |
The ResultSet provider already had an IdFactory in hand, so we can just use that.
440a356
to
09bd48b
Compare
When we're creating a ResultSet for a symbol, we always attach a moniker on it once it's created. We do that outside the main lock against the dictionary for all symbols, so that way the creation of the moniker isn't holding up operations for unrelated symbols. This was fine because nothing cared about the moniker existing, until we added additional support for inheritance, and the new spec now needs us to link to monikers in some cases. There I put in an incorrect assumption that the moniker might be there, which isn't the case if a different thread is still making it. Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1692879
09bd48b
to
82898be
Compare
When we're creating a ResultSet for a symbol, we always attach a moniker on it once it's created. We do that outside the main lock against the dictionary for all symbols, so that way the creation of the moniker isn't holding up operations for unrelated symbols. This was fine because nothing cared about the moniker existing, until we added additional support for inheritance, and the new spec now needs us to link to monikers in some cases. There I put in an incorrect assumption that the moniker might be there, which isn't the case if a different thread is still making it.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1692879