-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Avoid searching entire trees when looking for implicit constructors in find-refs #73625
Conversation
return _identifierCache.GetOrAdd( | ||
identifier, | ||
identifier => FindMatchingIdentifierTokensFromTree(identifier, cancellationToken)); | ||
} |
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 logic is the smae.
identifier => FindMatchingTokensFromText( | ||
identifier, | ||
static (identifier, token, @this) => @this.IsMatch(identifier, token), | ||
this, cancellationToken)); |
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 is almost hte same. just the addition of hte lambdaA+args to call nito a unified helper here.
if (!state.Cache.SyntaxTreeIndex.ContainsImplicitObjectCreation) | ||
return; | ||
|
||
// Note: only C# supports implicit object creation. So we don't need to do anything special around case |
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.
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.
it technically doesn't. it was just easier this way.
...kspaces/Core/Portable/FindSymbols/FindReferences/Finders/ConstructorSymbolReferenceFinder.cs
Outdated
Show resolved
Hide resolved
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 current approach walks the whole tree for any file that we know has an implicit-object-creation expression in it (e.g.
new(...)
). This is because we don't know what that expression will bind to, and we have to test each out.However, walkign the entire tree looking for these is unnecessary. We can instead search the docs containing such nodes for the
new
tokens in them, and see if they start anew(...)
node. This means we only have to walk those small subset of tokens. This addresses about 5% of the cost when doing a FAR on a named-type: