Bring back naive implementation of FAR for target-typed new#43645
Bring back naive implementation of FAR for target-typed new#43645jcouv merged 4 commits intodotnet:masterfrom
Conversation
|
I thought we were going to go with an approach using a background incremental analyzer to build a special index for these. #Closed |
|
@CyrusNajmabadi Yes, but we also discussed making progress by enabling the scenario and getting a sense of the perf problem. This PR would allow us to modify Roslyn with some target-typed new and get a feel. What do you think? #Closed |
Got it. For me, i thought we were saying that we woudl more do it as an experiment. i.e. it's fine to have this is draft, and use it to get some perf numbers. But i'm not sure i would want to preemptively merge things until we had that info. Is that ok with you? #Closed |
|
Re-opened PR following experiment we discussed. In short: |
This reverts commit 6808612.
|
@CyrusNajmabadi I rebased to resolve conflicts. Feel free to take another look when you have time. #Closed |
| </Workspace> | ||
| Await TestAPIAndFeature(input, kind, host) | ||
| End Function | ||
|
|
There was a problem hiding this comment.
| ``` #Resolved |
| End Function | ||
|
|
||
| End Class | ||
| End Namespace |
There was a problem hiding this comment.
we should have some additional tests. for example, we should verify that reorder parameters (and all our other sig-change features) doesn't crash. if it does the right ting, great! if it doesn't open bug.
@dpoeschl can give you a full list. #Resolved
There was a problem hiding this comment.
ChangeSignature indeed has some problems. Opened #44126 #Resolved
src/Workspaces/Core/Portable/FindSymbols/FindReferences/Finders/AbstractReferenceFinder.cs
Show resolved
Hide resolved
| } | ||
|
|
||
| private bool IsConstructor(IMethodSymbol methodSymbol) | ||
| => methodSymbol.MethodKind == MethodKind.Constructor; |
There was a problem hiding this comment.
- don't know if this method feels warranted :)
- static #Resolved
| [SuppressMessage("CodeQuality", "IDE0051:Remove unused private members", Justification = "Private constants are used for static assertions.")] | ||
| internal static class SyntaxKindEx | ||
| { | ||
| public const SyntaxKind ImplicitObjectCreationExpression = (SyntaxKind)8659; |
There was a problem hiding this comment.
can you add teh same overflow check below in #!CODE_STYLE? #Resolved
| if (node.Kind() == Formatting.SyntaxKindEx.ImplicitObjectCreationExpression) | ||
| { | ||
| var info = semanticModel.GetSymbolInfo(node); | ||
| return (IMethodSymbol)info.Symbol; |
There was a problem hiding this comment.
is this what we do for normal constructors? i.e. this is ignoring candidates in the case of errors? if that is what we do normally, grat. but if we normally use any/all of the symbols we get back for a normal constructor, then we should follow that here. #Resolved
There was a problem hiding this comment.
also, i don't think this method is needed. it is necessary when we'll need some sort of funky semantic model call to get specific information (like foreach-info), but for FAR, it could just call .GetSymbolInfo(node) since it already knows it's an implici-obje-expr. #Resolved
There was a problem hiding this comment.
I had not thought of that. As far as I understand, the logic for FAR on constructors will only consider non-error symbols (uses GetSymbolInfo(...).Symbol only, ignoring candidates):
protected static Func<SyntaxNode, SemanticModel, (bool matched, CandidateReason reason)> GetStandardSymbolsNodeMatchFunction(
ISymbol searchSymbol, Solution solution, CancellationToken cancellationToken)
{
return (node, model) =>
{
var symbolInfoToMatch = FindReferenceCache.GetSymbolInfo(model, node, cancellationToken);
var symbolToMatch = symbolInfoToMatch.Symbol;
var symbolToMatchCompilation = model.Compilation;
if (SymbolFinder.OriginalSymbolsMatch(searchSymbol, symbolInfoToMatch.Symbol, solution, null, symbolToMatchCompilation, cancellationToken))
{
return (matched: true, CandidateReason.None);
}
else if (symbolInfoToMatch.CandidateSymbols.Any(s => SymbolFinder.OriginalSymbolsMatch(searchSymbol, s, solution, null, symbolToMatchCompilation, cancellationToken)))
{
return (matched: true, symbolInfoToMatch.CandidateReason);
}
else
{
return (matched: false, CandidateReason.None);
}
};
}
In reply to: 422305225 [](ancestors = 422305225)
| var ordinaryRefs = await FindOrdinaryReferencesAsync(symbol, document, semanticModel, findParentNode, cancellationToken).ConfigureAwait(false); | ||
| var attributeRefs = await FindAttributeReferencesAsync(symbol, document, semanticModel, cancellationToken).ConfigureAwait(false); | ||
| var predefinedTypeRefs = await FindPredefinedTypeReferencesAsync(symbol, document, semanticModel, cancellationToken).ConfigureAwait(false); | ||
| var implicitOjbectCreationMatches = await FindReferencesInImplicitObjectCreationExpressionAsync(symbol, document, semanticModel, cancellationToken).ConfigureAwait(false); |
| var implicitOjbectCreationMatches = await FindReferencesInImplicitObjectCreationExpressionAsync(symbol, document, semanticModel, cancellationToken).ConfigureAwait(false); | ||
|
|
||
| return ordinaryRefs.Concat(attributeRefs).Concat(predefinedTypeRefs); | ||
| return ordinaryRefs.Concat(attributeRefs).Concat(predefinedTypeRefs).Concat(implicitOjbectCreationMatches); |
There was a problem hiding this comment.
aside, do we have a Concat that takes in multiple Immutable arrays. it's a pity about all these copies. #Resolved
There was a problem hiding this comment.
We don't have such a Concat overload. Added #Resolved
CyrusNajmabadi
left a comment
There was a problem hiding this comment.
LGTM. can you fix ojbect? (either in this PR or a followup).
This reverts commit 6808612.
Relates to #28489
Fixes #42555