Skip to content

Bring back naive implementation of FAR for target-typed new#43645

Merged
jcouv merged 4 commits intodotnet:masterfrom
jcouv:far-new
May 11, 2020
Merged

Bring back naive implementation of FAR for target-typed new#43645
jcouv merged 4 commits intodotnet:masterfrom
jcouv:far-new

Conversation

@jcouv
Copy link
Member

@jcouv jcouv commented Apr 24, 2020

This reverts commit 6808612.

Relates to #28489

Fixes #42555

@jcouv jcouv added the Area-IDE label Apr 24, 2020
@jcouv jcouv added this to the 16.7 milestone Apr 24, 2020
@jcouv jcouv self-assigned this Apr 24, 2020
@CyrusNajmabadi
Copy link
Contributor

CyrusNajmabadi commented Apr 24, 2020

I thought we were going to go with an approach using a background incremental analyzer to build a special index for these. #Closed

@jcouv
Copy link
Member Author

jcouv commented Apr 24, 2020

@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

@CyrusNajmabadi
Copy link
Contributor

CyrusNajmabadi commented Apr 24, 2020

This PR would allow us to modify Roslyn with some target-typed new and get a feel. What do you think?

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

@jcouv jcouv marked this pull request as ready for review April 24, 2020 19:13
@jcouv jcouv requested a review from a team as a code owner April 24, 2020 19:13
@jcouv jcouv requested a review from CyrusNajmabadi April 24, 2020 19:13
@jcouv jcouv marked this pull request as draft April 24, 2020 21:49
@jcouv jcouv marked this pull request as ready for review May 7, 2020 17:15
@jcouv
Copy link
Member Author

jcouv commented May 7, 2020

Re-opened PR following experiment we discussed.

In short:
I changed about half of object creations in CodeAnalysis.CSharp to use target-type new.
Then did a FindAllReferences on a few constructors. Also added some edits (adding a new type) in the mix.
The performance seems similar to invoking FindAllReferences on a popular method name (like Equals), which is what we’d expect. #Closed

@jcouv
Copy link
Member Author

jcouv commented May 8, 2020

@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

Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
``` #Resolved

End Function

End Class
End Namespace
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@jcouv jcouv May 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ChangeSignature indeed has some problems. Opened #44126 #Resolved

}

private bool IsConstructor(IMethodSymbol methodSymbol)
=> methodSymbol.MethodKind == MethodKind.Constructor;
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. don't know if this method feels warranted :)
  2. 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;
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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;
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@jcouv jcouv requested a review from CyrusNajmabadi May 11, 2020 16:24
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);
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ojbect #Resolved

var implicitOjbectCreationMatches = await FindReferencesInImplicitObjectCreationExpressionAsync(symbol, document, semanticModel, cancellationToken).ConfigureAwait(false);

return ordinaryRefs.Concat(attributeRefs).Concat(predefinedTypeRefs);
return ordinaryRefs.Concat(attributeRefs).Concat(predefinedTypeRefs).Concat(implicitOjbectCreationMatches);
Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi May 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aside, do we have a Concat that takes in multiple Immutable arrays. it's a pity about all these copies. #Resolved

Copy link
Member Author

@jcouv jcouv May 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have such a Concat overload. Added #Resolved

Copy link
Contributor

@CyrusNajmabadi CyrusNajmabadi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. can you fix ojbect? (either in this PR or a followup).

@jcouv jcouv requested a review from a team as a code owner May 11, 2020 20:51
@jcouv jcouv merged commit 7179688 into dotnet:master May 11, 2020
@ghost ghost modified the milestones: 16.7, Next May 11, 2020
@jcouv jcouv deleted the far-new branch May 11, 2020 23:15
@jcouv jcouv mentioned this pull request May 11, 2020
50 tasks
@JoeRobich JoeRobich modified the milestones: Next, 16.7.P2 May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FindAllReferences and target-typed new

3 participants