Refactoring in preparation for D153131
Details
Diff Detail
Event Timeline
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. |
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.
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.
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.
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. | |
1604–1606 | Something went wrong with the indentation here, also in the following ifs. Should be two spaces only. |
clang/lib/Analysis/ThreadSafety.cpp | ||
---|---|---|
1604–1606 | This is weird. clang-format insists on putting 4 spaces there. I've reverted the changes manually. |
Why the alias? I find this just obfuscates.