Skip to content
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

Remove portions of SolutionCrawler not used by UnitTesting team. #64330

Conversation

CyrusNajmabadi
Copy link
Member

Should be removed commit by commit.

@CyrusNajmabadi CyrusNajmabadi requested review from a team as code owners September 27, 2022 23:00
@CyrusNajmabadi CyrusNajmabadi changed the base branch from main to features/solutionEvents September 27, 2022 23:00
highPriorityForActiveFile: false,
#endif
Copy link
Member Author

Choose a reason for hiding this comment

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

unit testing always passes 'false' for this value. so no point in having it.

@@ -25,6 +25,7 @@ public Task AnalyzeDocumentAsync(Document document, SyntaxNode bodyOpt, UnitTest
public Task AnalyzeProjectAsync(Project project, bool semanticsChanged, UnitTestingInvocationReasons reasons, CancellationToken cancellationToken)
=> _implementation.AnalyzeProjectAsync(project, semanticsChanged, reasons, cancellationToken);

#if false // Not used in unit testing crawling
Copy link
Member Author

Choose a reason for hiding this comment

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

all the methods that unit testing just returns Task.CompletedTask are not necessary to support. so each commit ifdefs one out and works backwards, removing anything uneeded.

@@ -23,10 +25,14 @@ internal interface IUnitTestingIncrementalAnalyzer
Task DocumentResetAsync(Document document, CancellationToken cancellationToken);

Task AnalyzeSyntaxAsync(Document document, UnitTestingInvocationReasons reasons, CancellationToken cancellationToken);
#endif

Task AnalyzeDocumentAsync(Document document, SyntaxNode bodyOpt, UnitTestingInvocationReasons reasons, CancellationToken cancellationToken);
Task AnalyzeProjectAsync(Project project, bool semanticsChanged, UnitTestingInvocationReasons reasons, CancellationToken cancellationToken);

Task RemoveDocumentAsync(DocumentId documentId, CancellationToken cancellationToken);
Copy link
Member Author

Choose a reason for hiding this comment

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

these three methods are the only thing unit testing actually uses.

foreach (var analyzer in analyzers)
{
analyzer.LogAnalyzerCountSummary();
}
#endif
Copy link
Member Author

Choose a reason for hiding this comment

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

an example of working backwards. becausse unit testing doesn't use LogAnalyzerCountSummary, we ifdefed it out. so this loop here is also unnecessary.

initializeLazily: true,
#endif
Copy link
Member Author

Choose a reason for hiding this comment

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

as this is always passed 'true' in, it's not needed as an actual customization flag and has been removed.

private readonly UnitTestingHighPriorityProcessor _highPriorityProcessor;
#endif
Copy link
Member Author

Choose a reason for hiding this comment

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

no need for a high-pri-processor at all as unit testing says that its analyzer doesn't get high pri processing privileges on any event. (i still need to see if we need the low pri one).

if (!initializeLazily)
{
// realize all analyzer right away
_ = lazyActiveFileAnalyzers.Value;
_ = lazyAllAnalyzers.Value;
}
#endif
Copy link
Member Author

Choose a reason for hiding this comment

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

since initializeLazily is always true, no need to do this realization work.

@@ -352,6 +361,7 @@ private async Task ProcessDocumentAsync(ImmutableArray<IUnitTestingIncrementalAn
await ProcessOpenDocumentIfNeededAsync(analyzers, workItem, textDocument, isOpen, cancellationToken).ConfigureAwait(false);
await ProcessCloseDocumentIfNeededAsync(analyzers, workItem, textDocument, isOpen, cancellationToken).ConfigureAwait(false);
}
#endif
Copy link
Member Author

Choose a reason for hiding this comment

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

note: as unit testing doesn't care abotu open/close events, the next pr removes those events from teh ones that VS will send to OOP.

Copy link
Contributor

@shyamnamboodiripad shyamnamboodiripad Sep 28, 2022

Choose a reason for hiding this comment

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

I'm curious whether this would have triggered analysis that would have called AnalyzeDocument() on the UT analyzer when files are opened (and whether commenting it out can cause any change in semantics esp. if we want to keep the highPriorityForActiveFiles flag above). I am assuming not - but the 'if needed' in the name of the above API prompted this question...

(For example, would tests from a document that was opened have been discovered faster because of the above calls? Would commenting it out mean that opening a document no longer expediates discovery of contained tests. The example is hypothetical - but wanted to check if we would see any subtle changes in semantic like that by commenting this out...)

Copy link
Member Author

Choose a reason for hiding this comment

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

so all ProcessOpenDocumentIfNeededAsync does it run the DocumentOpenAsync method on all registered analyzers. so for UnitTesting that was a no-op. So these two calls were no ops. so i if'def'ed it out. :)

highPriorityForActiveFile: false,
#endif
Copy link
Contributor

@shyamnamboodiripad shyamnamboodiripad Sep 28, 2022

Choose a reason for hiding this comment

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

I am surprised by this. My assumption was that the crawler always prioritized analysis in active files (and was not aware that analyzers need to opt-in for this). I wonder if we are leaving some responsiveness on the table (for test discovery) by setting this to false.

Is there any harm in preserving this so that we could experiment with switching this to true down the line?

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'm preservinb this by keeping the code in teh ifdef around. when you guys take over this, you can totally try flipping the switch on this. but i'm not a fan of speculatively keeping this around with all the complexity when it's not even being used currently, and all this code is going to be 'legacy' and ideally replaced with something better asap :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Fair enough. So long as the code is available, we can experiment with it.

The only reason I was asking is that this could be an easy perf win that users would notice (especially when adding tests within larger solutions). It would be faster to experiment and improve the user experience with the existing code than to say that we need to first move over to a pull-based model before we can do that :)

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 think that's totally fine :) that's why i'm leaving the code in there. you can def add/augment it going forward to try things out. my hope though is that we can start with an extremely small and lightweight kernel that is easy to maintain versus having to pull in everything in the crawler space.

@@ -84,5 +87,7 @@ public void LogAnalyzerCountSummary()
public void Shutdown()
Copy link
Contributor

Choose a reason for hiding this comment

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

The nested #if false above can probably be removed.

Copy link
Member Author

Choose a reason for hiding this comment

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

will do.

@@ -95,11 +96,13 @@ public void Enqueue(UnitTestingWorkItem item)
return;
}

#if false // Not used in unit testing crawling
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this is nested inside another #if false and can potentially be omitted

Copy link
Member Author

Choose a reason for hiding this comment

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

will do.

Copy link
Contributor

@shyamnamboodiripad shyamnamboodiripad left a comment

Choose a reason for hiding this comment

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

:shipit: 👍🏾

@CyrusNajmabadi CyrusNajmabadi merged commit 6e189ab into dotnet:features/solutionEvents Sep 28, 2022
@CyrusNajmabadi CyrusNajmabadi deleted the diabledUnusedFunctionality branch September 28, 2022 19:04
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.

2 participants