Instead of one long function, MemRegionManager::getVarRegion now calls getMemRegionGloballyStored for global, non-static variables, and getMemRegionStaticLocal for static locals. The behavior of MemRegionManager::getVarRegion is thus clearer, and easier to reason about.
Details
Diff Detail
Event Timeline
Thanks ariccio! Some inline comments are below.
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
---|---|---|
1186 | How about make these helper functions return const MemSpaceRegion * to make their signatures more meaningful? | |
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
834 | get[Global/StaticLocal]MemSpaceForVariable? | |
853 | const MemSpaceRegion *StorageSpace? |
Responded to comments.
Will happily make changes when questions are answered.
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
---|---|---|
1186 | Would that change their behavior functionally? | |
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
834 | Ahh, that might make more sense. I did this refactoring without any sense of context, as the unnecessary complexity was a hindrance thereto. | |
834 | How about getGlobalMemSpaceForGlobalVariable? I'm hesitant to drop the second global, to be clear about the scope of the variable that's stored globally. Is that a reasonable concern, or is that redundant? | |
853 | Same question as above: Would that change their behavior functionally? (if not, then I'll happily change it) |
I guess this is a reasonable refactoring. Although someone with different tastes might come along and inline it back in since the two extracted functions each only have single callers.
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
---|---|---|
1185 | I think describing this as taking a "globally stored, non-static local, VarDecl" is ambiguous. This method operates on global variables. It does not act on local variables (static or otherwise). How about "Retrieve or create the memory region associated with a VarDecl for a global variable." Also, the recommended style these days is to not prefix the doc comment with the name of the member, so I would remove "getMemRegionGloballyStored - " even though getVarRegion() has the same thing. The doc comment style in this file is sufficiently mismatched that I think it is better to do the now-recommend thing rather than try to match its surrounding context. | |
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
834 | The rest of the method in class follow a pattern of getAdjectiveNoun, so I would suggest something like getGlobalVarRegion() and getLocalVarRegion() | |
838–839 | It looks to me like this function operates on both locals *and* static locals. I would change the name to reflect that. | |
858 | This comment was wrong before and very misleading. I would just remove it so no one else trips on it! |
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
---|---|---|
1186 | No, it will not change it. You will need to change static_cast type to const MemSpaceRegion *, however (lines 809-810). There is const MemSpaceRegion * and its children classes everywhere in return statements already. | |
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
853 | No, this will not. |
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
---|---|---|
845 | Oops. |
Whoops, I didn't submit my comments.
llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h | ||
---|---|---|
1185 | I like that. Done. | |
1186 | What're the static_cast<const MemRegion*>s for anyways? Shouldn't the const StackArgumentsSpaceRegion*s convert to const MemRegion* automatically? StackArgumentsSpaceRegion derives from StackSpaceRegion: class StackArgumentsSpaceRegion : public StackSpaceRegion ...StackSpaceRegion derives from MemSpaceRegion: class StackSpaceRegion : public MemSpaceRegion ...and MemSpaceRegion derives from MemRegion: class MemSpaceRegion : public MemRegion ...which I think should work, because of the kooky rules of covariant return types (or something)? | |
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
834 | Whatever. I've changed the global one to getGlobalVarRegion. | |
838–839 | So, getMemRegionStaticLocalOrLocal? | |
845 | Nice catch! That's exactly why we do code review :)
We might not want to change the return type, I see. |
I think Aleksei is right and I was wrong.
If you follow his advice and move the call to getStackOrCaptureRegionForDeclContext() to getVarRegion() and then pass the StackFrameContext to what you currently name "getMemRegionStaticLocal" then both methods have the very nice property that they return memory space regions and all the VarRegion stuff is kept in the caller.
In my opinion getMemSpaceForGlobalVariable() and getMemSpaceForLocalVariable() are good names for these two new methods. If you prefer 'getMemSpaceForStaticLocalOrLocalVariable()' I think that would be fine too.
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
---|---|---|
792 | That needs to be formatted. Also, you may pass const StackFrameContext * instead of PointerUnion (as Devin pointed) because it is only used once to get SFC. |
One of two comments addressed, one question asked.
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
---|---|---|
792 | If I change it to a MemSpaceRegion*, do I need to change the static_casts, from: ? static_cast<const MemRegion*>(getStackArgumentsRegion(STC)) : static_cast<const MemRegion*>(getStackLocalsRegion(STC))); to: ? static_cast<const MemSpaceRegion*>(getStackArgumentsRegion(STC)) : static_cast<const MemSpaceRegion*>(getStackLocalsRegion(STC))); ...? I'm still not quite sure what they're for in the first place? |
I've reformatted, and changed the PointerUnion to a const StackFrameContext*.
Built successfully, etc...
(I hope I don't sound too pushy!)
llvm/tools/clang/lib/StaticAnalyzer/Core/MemRegion.cpp | ||
---|---|---|
792 | I'm sorry, I think you're right, but I wanna get this patch over with, so I can move on to other things. Some other time, maybe? |
Hello Alexander,
Yes, types in static_cast should be changed. So, you need only to change return type and types in static_cast, and it should work.
It's become a zombie review. I should just abandon it, as I'll be away for two weeks starting tomorrow.
I think describing this as taking a "globally stored, non-static local, VarDecl" is ambiguous. This method operates on global variables. It does not act on local variables (static or otherwise). How about "Retrieve or create the memory region associated with a VarDecl for a global variable."
Also, the recommended style these days is to not prefix the doc comment with the name of the member, so I would remove "getMemRegionGloballyStored - " even though getVarRegion() has the same thing. The doc comment style in this file is sufficiently mismatched that I think it is better to do the now-recommend thing rather than try to match its surrounding context.