- User Since
- Jul 7 2012, 2:55 PM (367 w, 1 d)
Mon, Jul 8
Fri, Jun 28
Jun 6 2019
May 27 2019
May 23 2019
May 20 2019
May 8 2019
Apr 13 2019
Apr 12 2019
Apr 11 2019
Apr 9 2019
Apr 8 2019
Apart from the typo I think this is a simple enough change and a widely enough used style that it LG.
+1 to quite some overlap in the tests. I'd have expected three test cases:
- ; line comment
- ; C-comment
- no semi
Apr 7 2019
The previous behavior looks intentional, and much more regular. I'd be curious why you think the proposed behavior is more readable.
Apr 5 2019
Mar 28 2019
I just verified why this doesn't break for our CI:
The trick is that if the indent is actually off (as opposed to being correct, but tab vs spaces), we do re-indent until we find an indent that's correct.
The fix that would make me happier, I think, is to do the same thing here:
Basically, when we expand the range until nothing changes, do not only check whether the indent is correct, but also whether we'd change the spaces in the indent.
Mar 25 2019
Minus me understanding the TT_TemplateString change, the rest looks nice now, thanks!
Oh, and LG :)
Mar 22 2019
Mar 21 2019
LG. This looks pretty sharp (scnr).
Great idea! LG from my side after addressing MyDeveloperDay's comments.
Mar 20 2019
I don't understand yet why running clang-format locally would not do the same change?
Mar 18 2019
Mar 15 2019
Mar 14 2019
problem is the olden C++ problem clang-format will never be able to solve, thus all these crazy heuristics.
IIRC this was done due to performance problems in large nested initializer lists. Can you verify this doesn't regress performance?
Given this doesn't add an extra option (but only an extra enum) and is fairly straight forward, LG.
Can you provide some evidence:
- that this is in a style guide that's used widely enough
- why you believe this matters
Why did the numeric constant break this? Which path would the function run through?
Mar 1 2019
Feb 22 2019
Feb 21 2019
Jan 17 2019
Jan 10 2019
Just in general, I'd like to add that my experience over the years dealing with folks trying to do AST matchers is that the inability to express something is much more of a problem than matching too much, simply because the test cases people think of are usually small, and when running a transformation on a very large codebase, the cost of false negatives is significantly higher than the cost of false positive: the cost of a false negative means that you may produce something incorrect. The cost of a false positive is that you adapt your matcher to exclude the false negative.
Jan 9 2019
Jan 4 2019
Dec 11 2018
Dec 7 2018
Nov 29 2018
Nov 28 2018
Nov 13 2018
Thanks Aaron for volunteering, I'm very thankful for all your work on the reviews, it's much appreciated :D
Nov 6 2018
Nov 5 2018
Oct 4 2018
Sep 3 2018
Aug 27 2018
Aug 21 2018
Aug 1 2018
Sorry that I lost track of that, but feel free to ping once / week - unfortunately the patch doesn't apply cleanly, can you rebase?
The problem here is that we have different opinions on how the formatting on namespace macros should behave in the first place- I think they should behave like namespaces, you want them to be formatted differently.
Given that you want full control over the formatting of those macros, and them not actually be formatted exactly like namespaces or classes, I think we need a more generic mechanism for you to express that.
Yea, if we go down this route I'd go with this by default:
some ? thing : else ? otherthing : unrelated ? but : finally;
Jul 26 2018
Usually we use match(anyOf(node), hasDescendant(node)). Or did I misunderstand what you want?