-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Conversation
I am not sure on the test failure. It seems unrelated. Stack trace
|
@@ -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 |
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.
I think you can just delete this? It looks legitimately unused.
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.
I thought that too, but I think the constructor calls to create a new singleton. Which then resets some things. Its very strangely structured.
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.
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.
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.
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
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.
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.
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 should be safe to put
_ = new ResetDefaultBuildManager();
in the constructor and delete the field.
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.
@ladipro
The constructor is here:
msbuild/src/Shared/UnitTests/TestEnvironment.cs
Lines 58 to 63 in 597d77e
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?
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.
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.
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.
@Forgind happy with these changes? When the team comes back they can have a look at the |
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 👍 |
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? |
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.
LGTM. The changes to HashSet fall under "unnecessary methods and attributes if-deffed out," so I don't think the comment needs changing.
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.
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 |
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 should be safe to put
_ = new ResetDefaultBuildManager();
in the constructor and delete the field.
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. |
Relates to #7174