Passionate test-driven developer
User Details
- User Since
- Jul 15 2013, 12:45 PM (462 w, 4 d)
Yesterday
- Add C++ test case for acceptable operator, initializer
- Update from review comments
- Disallow operator, unless inside parentheses
Thu, May 26
Mon, May 23
Update from review comments
Another observation:
If some new pattern comes up and fixits aren't recognized for a check, it might be better
to switch to a whitelist for checks with fixits rather than going crazier on the file scraping.
LGTM
Sat, May 21
Fri, May 20
Are we waiting on some sort of benchmark before accepting/rejecting this change?
If the only thing holding this up is my comments about following the Law of Demeter, I don't think that should block submitting this change.
LGTM
LGTM
Address one nit and ship.
Thu, May 19
Wed, May 18
LGTM
Discarding in favor of Nathan James's improved implementation.
LGTM! Thanks for taking my idea and implementing it much better than what I had :).
LGTM
Another good catch!
Good catch!
Tue, May 17
Just for my own edification, how did you know/suspect that a pure visitor would be faster than matchers?
I thought there wasn't any support for validating fixits applied to header files?
Mon, May 16
Sat, May 14
Fri, May 13
Update documentation from review comments
Mon, May 9
Sun, May 8
OK, so thinking about this review a little more, I propose this:
- Take the check as is, but document that the initializing expressions may result in an invalid enum, particularly for C which restricts the underlying type to be int
- Create a subsequent commit that rejects the enums where the language is C and the initializing expression is a value larger than an int by rejecting any macro where any integer token in the expression is larger than an int
- Create an additional subsequent commit that not only matches the expression but also computes the value and checks it for range.
Mon, May 2
Sun, May 1
I also noticed that some of the simplifications being performed resulted in !(x || !y) coming out of other parts of the simplifier, so it should be the case that running this check on your code should result in no further changes to your code if you run the check again.
Testing on VTK revealed this change:
- this->SliceMapper->SetBackground((this->Background && - !(this->SliceFacesCamera && this->InternalResampleToScreenPixels && - !this->SeparateWindowLevelOperation))); + this->SliceMapper->SetBackground( + (this->Background && + (!this->SliceFacesCamera && this->InternalResampleToScreenPixels || + this->SeparateWindowLevelOperation)));
Which is incorrect. So more improvement is needed for the case of !(x && y && !z) or !(x || y || !z) is encountered.
Sat, Apr 30
FYI, once nice addition of the parsing of macro bodies is that it paves the way for
a modernize-macro-to-function check that converts function-like macros that
compute values to template functions. Once this change has landed, I'll be putting
up a review for that.
Recognize comma operator expressions
Fri, Apr 29
Surround replacements with parens
Update from review comments
Sort changes by check name in docs
Thu, Apr 28
General question:
Apr 27 2022
Update documentation
Add file block comment
Apr 26 2022
Inline Variable
- Add banner block comment for new files
- Extract Functions to eliminate duplication
Update from review comments
Apr 25 2022
Gentle ping.