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

CA1823 Avoid unused private fields #7180

Merged
merged 9 commits into from
Jan 26, 2022
Merged

CA1823 Avoid unused private fields #7180

merged 9 commits into from
Jan 26, 2022

Conversation

elachlan
Copy link
Contributor

Relates to #7174

@elachlan
Copy link
Contributor Author

I am not sure on the test failure. It seems unrelated.

Stack trace

Shouldly.ShouldAssertException : _httpListenerThreadException\n    should be null but was\nSystem.Net.HttpListenerException (0x80004005): The process cannot access the file because it is being used by another process\r\n   at System.Net.HttpListener.AddAllPrefixes()\r\n   at System.Net.HttpListener.Start()\r\n   at Microsoft.Build.UnitTests.Evaluation.Evaluator_Tests.HttpServerThread() in D:\a\1\s\src\Build.UnitTests\Evaluation\Evaluator_Tests.cs:line 4843
   at Shouldly.ShouldBeNullExtensions.ShouldBeNull[T](T actual, Func`1 customMessage)
   at Shouldly.ShouldBeNullExtensions.ShouldBeNull[T](T actual)
   at Microsoft.Build.UnitTests.Evaluation.Evaluator_Tests.VerifyDTDProcessingIsDisabled2() in D:\a\1\s\src\Build.UnitTests\Evaluation\Evaluator_Tests.cs:line 4288

@@ -20,7 +20,9 @@ namespace Microsoft.Build.UnitTests
public partial class TestEnvironment
{
// reset the default build manager and the state it might have accumulated from other tests
#pragma warning disable CA1823 // Avoid unused private fields
Copy link
Member

Choose a reason for hiding this comment

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

I think you can just delete this? It looks legitimately unused.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought that too, but I think the constructor calls to create a new singleton. Which then resets some things. Its very strangely structured.

Copy link
Member

Choose a reason for hiding this comment

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

I tried deleting it and running tests, and it passed tests. Evidence that it isn't used but not definitive.

The constructor refers to SingletonField and by reflection to s_singletonInstance on BuildManager, but I didn't see a reference to _resetBuildManager.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I actually have no idea. I felt it erred on the side of caution and used a suppression instead of deleting all the code.

So what I think is happening, is that the TestEnvironment class is used in different tests. When it is instantiated, it makes a call to the DefaultBuildManager to clean-up the environment.

This seems strange, because I would have thought this would have been done on dispose for the TestEnvironment since it is utilised in a using pattern.

The comment explains it best:
// reset the default build manager and the state it might have accumulated from other tests

Copy link
Member

Choose a reason for hiding this comment

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

I get it. I guess the idea was that if the environment was corrupted (i.e., not used in a using pattern, there are bugs, etc.), someone might go down a rabbit hole trying to figure out why. Worse, it would only happen if the tests were run in a particular order. I might claim that this then hides potential serious problems, but I guess it's fine to leave it in.

Copy link
Member

Choose a reason for hiding this comment

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

It should be safe to put

_ = new ResetDefaultBuildManager();

in the constructor and delete the field.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ladipro
The constructor is here:

private TestEnvironment(ITestOutputHelper output)
{
Output = output;
_defaultTestDirectory = new Lazy<TransientTestFolder>(() => CreateFolder());
SetDefaultInvariant();
}

But if I add it here, it cannot find the class when in the Microsoft.Build.Framework.UnitTests project. I am not sure how to get around this. Maybe a #if but if its used somewhere else it would have to be updated. So its not an elegant solution.

I don't suppose EngineTestEnvironment wasn't included in Microsoft.Build.Framework.UnitTests by accident?

Copy link
Member

Choose a reason for hiding this comment

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

Ah, I see, let's leave as is then. Maybe the better way to structure the code would be to make the Engine TestEnvironment derive from the base TestEnvironment instead of using partial classes but definitely out of scope here. Apologies for the randomization.

src/MSBuild.UnitTests/PerfLog_Tests.cs Outdated Show resolved Hide resolved
src/Build/Collections/RetrievableEntryHashSet/HashSet.cs Outdated Show resolved Hide resolved
@Forgind
Copy link
Member

Forgind commented Dec 30, 2021

I am not sure on the test failure. It seems unrelated.

Stack trace

Shouldly.ShouldAssertException : _httpListenerThreadException\n    should be null but was\nSystem.Net.HttpListenerException (0x80004005): The process cannot access the file because it is being used by another process\r\n   at System.Net.HttpListener.AddAllPrefixes()\r\n   at System.Net.HttpListener.Start()\r\n   at Microsoft.Build.UnitTests.Evaluation.Evaluator_Tests.HttpServerThread() in D:\a\1\s\src\Build.UnitTests\Evaluation\Evaluator_Tests.cs:line 4843
   at Shouldly.ShouldBeNullExtensions.ShouldBeNull[T](T actual, Func`1 customMessage)
   at Shouldly.ShouldBeNullExtensions.ShouldBeNull[T](T actual)
   at Microsoft.Build.UnitTests.Evaluation.Evaluator_Tests.VerifyDTDProcessingIsDisabled2() in D:\a\1\s\src\Build.UnitTests\Evaluation\Evaluator_Tests.cs:line 4288

It probably is—if it'll rerun if we push any more changes, or I can rerun it manually if not.

…d it to its own block. This way we avoid the Analyzer error and keeps the code logically grouped.
@elachlan
Copy link
Contributor Author

@Forgind happy with these changes? When the team comes back they can have a look at the #if NEVER blocks and remove them if they want.

@Forgind
Copy link
Member

Forgind commented Dec 31, 2021

@Forgind happy with these changes? When the team comes back they can have a look at the #if NEVER blocks and remove them if they want.

I'll be happy if we delete all the #if NEVER blocks 🙂 but if there's a good reason for them to exist, I'll accept it. Otherwise 👍

@elachlan
Copy link
Contributor Author

So should I remove the #if NEVER blocks?

@Forgind
Copy link
Member

Forgind commented Jan 10, 2022

So should I remove the #if NEVER blocks?

Sorry I got distracted—answer seems to be that we should avoid touching that file—and that was the point of the #if NEVER blocks. They aren't used, but if we need to merge in more changes from the original version of that file at some point, we want it as similar as possible without adding extra gunk to MSBuild assemblies. Adding #if NEVER means nothing unnecessary is added but also doesn't change the file very much. I'd suggest avoiding any changes to the file at all, sadly.

@elachlan
Copy link
Contributor Author

So should I remove the #if NEVER blocks?

Sorry I got distracted—answer seems to be that we should avoid touching that file—and that was the point of the #if NEVER blocks. They aren't used, but if we need to merge in more changes from the original version of that file at some point, we want it as similar as possible without adding extra gunk to MSBuild assemblies. Adding #if NEVER means nothing unnecessary is added but also doesn't change the file very much. I'd suggest avoiding any changes to the file at all, sadly.

Not a problem. I have left it alone. Should we be okay for merge?

@elachlan elachlan requested a review from Forgind January 18, 2022 22:56
Copy link
Member

@Forgind Forgind left a comment

Choose a reason for hiding this comment

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

LGTM. The changes to HashSet fall under "unnecessary methods and attributes if-deffed out," so I don't think the comment needs changing.

src/Tasks/ManifestUtil/Util.cs Outdated Show resolved Hide resolved
Copy link
Member

@ladipro ladipro left a comment

Choose a reason for hiding this comment

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

Some of the unused fields may serve the documentation purpose and the const ones have no run-time perf impact altogether. I believe enabling the rule is goodness, though. I've left one inline comment.

@@ -20,7 +20,9 @@ namespace Microsoft.Build.UnitTests
public partial class TestEnvironment
{
// reset the default build manager and the state it might have accumulated from other tests
#pragma warning disable CA1823 // Avoid unused private fields
Copy link
Member

Choose a reason for hiding this comment

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

It should be safe to put

_ = new ResetDefaultBuildManager();

in the constructor and delete the field.

@ladipro ladipro added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Jan 26, 2022
@ladipro ladipro merged commit 96d7bbc into dotnet:main Jan 26, 2022
@danmoseley
Copy link
Member

Not on the team, but I created those blocks/copied HashSet originally: I don't think they are worth keeping. They reflect the sources in .NET Framework, sources which no longer change. There have indeed been improvements to HashSet, but in .NET Core, where the code is changed enough there that diffing would not work well and changes would need to be ported by hand anyway.

@danmoseley
Copy link
Member

@Forgind I opened #7340 for that suggestion.

@elachlan elachlan deleted the CA1823 branch January 26, 2022 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants