This is an archive of the discontinued LLVM Phabricator instance.

[clang analysis][NFCI] Preparatory work for D153131.
ClosedPublic

Authored by courbet on Jun 16 2023, 6:06 AM.

Details

Summary

Refactoring in preparation for D153131

Diff Detail

Event Timeline

courbet created this revision.Jun 16 2023, 6:06 AM
Herald added a project: Restricted Project. · View Herald Transcript
courbet requested review of this revision.Jun 16 2023, 6:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 16 2023, 6:06 AM

Is this actually required for the subsequent change? I don't see the connection.

That being said, I haven't spent a lot of thought on what belongs in ThreadSafetyAnalyzer and what in BuildLockset.

clang/lib/Analysis/ThreadSafety.cpp
1541

Why the alias? I find this just obfuscates.

1588

Hmm, functions of the same class naturally want to be together, but if you move them, it "destroys" the Git history.

Is this actually required for the subsequent change? I don't see the connection.

In the followup change, we have to check the returns after the enter and exit CFG block are computed. We can't analyze the returns as they are seen because , because what matters for the returns is the locks that are live at the end of the function, not those that are live at the point where the return happens.

The BuildLockset class only lives for the duration of the analysis of a single block, while the ThreadSafetyAnalyzer lives for the whole function. So return checking is done in the ThreadSafetyAnalyzer, so we need the check/warn functions to be available here.

From a design perspective I think it might actually make more sens for them to be in the analyzer as warnIfMutexNotHeld and friends actually inspects quite a lot of the Analyzer state.

clang/lib/Analysis/ThreadSafety.cpp
1541

I'm using it one more time in the followup patch, but no strong opinion, removed.

1588

Yes, I decided to make review/history tracking esaier by not moving them, but I can move them if you want.

courbet updated this revision to Diff 532534.Jun 18 2023, 11:03 PM

remove type alias

Is this actually required for the subsequent change? I don't see the connection.

In the followup change, we have to check the returns after the enter and exit CFG block are computed. We can't analyze the returns as they are seen because , because what matters for the returns is the locks that are live at the end of the function, not those that are live at the point where the return happens.

Is this still the case? Or do we not need this anymore.

From a design perspective I think it might actually make more sens for them to be in the analyzer as warnIfMutexNotHeld and friends actually inspects quite a lot of the Analyzer state.

On that I agree.

Is this actually required for the subsequent change? I don't see the connection.

In the followup change, we have to check the returns after the enter and exit CFG block are computed. We can't analyze the returns as they are seen because , because what matters for the returns is the locks that are live at the end of the function, not those that are live at the point where the return happens.

Is this still the case? Or do we not need this anymore.

So the change we still actually need is for checkAccess() to take the fact set as a parameter (because we're checking two different fact sets depending on whether we're processing a return statement or not). I think that design-wise it's better if checkAccess is in the Analyzer rather than the BuildLockset, because checkAccess() no longer needs access to any state within BuildLockset.

From a design perspective I think it might actually make more sens for them to be in the analyzer as warnIfMutexNotHeld and friends actually inspects quite a lot of the Analyzer state.

On that I agree.

Is this actually required for the subsequent change? I don't see the connection.

In the followup change, we have to check the returns after the enter and exit CFG block are computed. We can't analyze the returns as they are seen because , because what matters for the returns is the locks that are live at the end of the function, not those that are live at the point where the return happens.

Is this still the case? Or do we not need this anymore.

So the change we still actually need is for checkAccess() to take the fact set as a parameter (because we're checking two different fact sets depending on whether we're processing a return statement or not). I think that design-wise it's better if checkAccess is in the Analyzer rather than the BuildLockset, because checkAccess() no longer needs access to any state within BuildLockset.

The patch without those base changes for reference: https://github.com/llvm/llvm-project/commit/11d3339daf6f3543d73292b307057769711bce2e.

From a design perspective I think it might actually make more sens for them to be in the analyzer as warnIfMutexNotHeld and friends actually inspects quite a lot of the Analyzer state.

On that I agree.

aaronpuchert accepted this revision.Sep 28 2023, 8:16 PM

Got it, so it's because we want to work on a different fact set than what BuildLockset holds.

Yeah, I think this makes sense. And after all the methods aren't too far away from the other ThreadSafetyAnalyzer methods.

clang/lib/Analysis/ThreadSafety.cpp
1019–1030

You could also put them in the public section. In fact your change would seem to get us pretty close to being able to unfriend BuildLockset.

1605–1608

Something went wrong with the indentation here, also in the following ifs. Should be two spaces only.

This revision is now accepted and ready to land.Sep 28 2023, 8:16 PM
courbet updated this revision to Diff 557475.Sep 29 2023, 1:26 AM
courbet marked 2 inline comments as done.

Address comments

courbet added inline comments.Sep 29 2023, 1:28 AM
clang/lib/Analysis/ThreadSafety.cpp
1605–1608

This is weird. clang-format insists on putting 4 spaces there. I've reverted the changes manually.

courbet closed this revision.Sep 29 2023, 1:39 AM