Details
- Reviewers
dcoughlin zaks.anna NoQ - Commits
- rG3d64d6ee5404: [Analyzer] Do not use static storage to for implementations created in BodyFarm.
rC316400: [Analyzer] Do not use static storage to for implementations created in BodyFarm.
rL316400: [Analyzer] Do not use static storage to for implementations created in BodyFarm.
Diff Detail
- Repository
- rL LLVM
Event Timeline
Content-wise, LGTM. There is a style nit inline.
Also, can you avoid reformatting the lines that haven't changed? This will help preserve the history of the file and make it clear what changes are related to your intended change in functionality.
lib/Analysis/AnalysisDeclContext.cpp | ||
---|---|---|
308 ↗ | (On Diff #119949) | Nit: Style-wise this is idiomatically written as: if (!BdyFrm) |
@dcoughlin that's not me, that's clang-format.
If we agree on always running it, I think the changes should stay there.
I think a good strategy is to look at your diffs and consider whether the benefits of normalizing the style outweigh the cost of losing the history. In this case, I think keeping the history makes sense. (Imagine you are a future maintainer and want to know when and why a new option was added. Is is very helpful to use git annotate to understand why the code is the way it is.)
@dcoughlin the context I was thinking about is that if everyone consistently runs clang-format (if we want that), then we never would have discussion.
The alternative is that every run of clang-format would be followed by manually reverting changes which were introduced by mistake (in this case, because the file was moved).
That would require going into the past and requiring everyone back then to run clang-format as well. Unfortunately they didn't -- so human judgment is needed when modifying code that doesn't obey the guidelines.
@dcoughlin OK sorry, I haven't considered the point that codebase predates the requirement, and the master format-all commit was never done.
I've committed this one already, but I will be more careful with applying clang-format to future changes.
cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp | ||
---|---|---|
607 | This is an almost guaranteed memory leak. I think, you meant if (BdyFrm) delete BdyFrm;. But delete deals well with nullptr, so just delete the pointer unconditionally. But first consider making BdyFrm a std::unique_ptr. From a cursory look I don't see any reasons not to. |
cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp | ||
---|---|---|
607 | @alexfh yes, this was fixed. |
This is an almost guaranteed memory leak. I think, you meant if (BdyFrm) delete BdyFrm;. But delete deals well with nullptr, so just delete the pointer unconditionally. But first consider making BdyFrm a std::unique_ptr. From a cursory look I don't see any reasons not to.