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

SE: Move CollectionConstraint from S4158 to the engine (part 5) #8728

Conversation

gregory-paidis-sonarsource
Copy link
Contributor

@gregory-paidis-sonarsource gregory-paidis-sonarsource commented Feb 9, 2024

Part of #7866

Moves MethodReference out of the rule.

Applies to:

var x = new List<int>();
DoWork(x.Add); // x.Add might be invoked inside DoWork, set x to Collection.NotEmpty

ITs will be fixed by part 6.

public static CollectionConstraint MethodReferenceConstraint(IMethodReferenceOperationWrapper operation) =>
operation.Instance is not null && AddMethods.Contains(operation.Method.Name)
? CollectionConstraint.NotEmpty
: null;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here we don't even check if the instance is typed as one of the tracked collection types.
Is this intended?
e.g. randomType.Add

Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch. Should be checked!

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'll keep a note for later, thanks!

protected override ProgramState Process(SymbolicContext context, IMethodReferenceOperationWrapper operation) =>
CollectionTracker.MethodReferenceConstraint(operation) is { } constraint
&& operation.Instance.TrackedSymbol(context.State) is { } symbol
? context.State.SetSymbolConstraint(symbol, constraint)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

before, we setted both the symbol and the operation of the instance.
I do not see a reason to set the instance operation of the MethodReference, since I don't think it can be re-used.

Copy link
Contributor

Choose a reason for hiding this comment

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

Probably fine. Then again, you got bitten by a very similar shortcut in the other PR.

public static CollectionConstraint MethodReferenceConstraint(IMethodReferenceOperationWrapper operation) =>
operation.Instance is not null && AddMethods.Contains(operation.Method.Name)
? CollectionConstraint.NotEmpty
: null;
Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch. Should be checked!

protected override ProgramState Process(SymbolicContext context, IMethodReferenceOperationWrapper operation) =>
CollectionTracker.MethodReferenceConstraint(operation) is { } constraint
&& operation.Instance.TrackedSymbol(context.State) is { } symbol
? context.State.SetSymbolConstraint(symbol, constraint)
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably fine. Then again, you got bitten by a very similar shortcut in the other PR.

IMethodReferenceOperationWrapper.FromOperation(operation);

protected override ProgramState Process(SymbolicContext context, IMethodReferenceOperationWrapper operation) =>
CollectionTracker.LearnFrom(context.State, operation);
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 could in-line this, but I think it's good to keep it in the tracker.
Mainly because:

  • I can hide the hashset properties
  • Almost everything is centralized there for CollectionConstraint.

Copy link
Contributor

@Tim-Pohlmann Tim-Pohlmann left a comment

Choose a reason for hiding this comment

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

Round 2

Copy link
Contributor

@Tim-Pohlmann Tim-Pohlmann left a comment

Choose a reason for hiding this comment

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

Changes are good but I just realized that I overlooked something: With the logic moving to the engine, we need UTs covering the new behavior in RoslynSymbolicExecutionTest.

Base automatically changed from greg/move-collection-constraint-4 to feature/move-collection-constraint February 13, 2024 13:54
@gregory-paidis-sonarsource
Copy link
Contributor Author

@Tim-Pohlmann I will add the tests on part-6, to have constraints added by invocations enabled, so that I am able to use .Clear, .Add, etc.

Copy link
Contributor

@Tim-Pohlmann Tim-Pohlmann left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link

sonarcloud bot commented Feb 13, 2024

Quality Gate Passed Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

Copy link

sonarcloud bot commented Feb 13, 2024

@gregory-paidis-sonarsource gregory-paidis-sonarsource marked this pull request as ready for review February 13, 2024 14:37
@pavel-mikula-sonarsource pavel-mikula-sonarsource merged commit 6a2c695 into feature/move-collection-constraint Feb 13, 2024
21 of 23 checks passed
@pavel-mikula-sonarsource pavel-mikula-sonarsource deleted the greg/move-collection-constraint-5 branch February 13, 2024 14:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants