User Details
- User Since
- Jul 7 2012, 2:55 PM (445 w, 2 d)
- Roles
- Administrator
Nov 26 2020
Isn't the comment incorrect after this patch?
Oct 28 2020
Adapted based on review comments.
Oct 22 2020
lg
Oct 7 2020
Nice catch, thanks! LG!
Sep 29 2020
Sep 28 2020
Sep 25 2020
FWIW, finding this due to seeing the added complexity. Do you have data on what the difference is on clang-format for either overall memory use or performance? Thanks!
Sep 19 2020
Worked in review comments.
Aug 20 2020
Aug 19 2020
Jul 29 2020
Addressed code review comments.
Jul 13 2020
Monday-morning ping.
@djasper wrote this iirc, but I doubt he'll have much time to look into this :)
Jul 9 2020
Jul 7 2020
Address review comment.
Jul 6 2020
Jul 3 2020
lg
Jun 30 2020
LG
Jun 29 2020
In what situation are we calling child matchers repeatedly with the same matcher on the same node?
Jun 22 2020
+Sam for additional sanity checking.
General note on that patch:
I am fine with both views, I know people who like to use arc land, I know people (like myself), who like to not have noisy messages.
I don't know that we have a good process to really decide that (Chris as BDFL dropped himself out of this one :)
I think giving folks a arcfilter line like Mehdi did is a great idea if we decide to go with the policy.
Jun 18 2020
Jun 16 2020
LG. Thanks!
Jun 15 2020
We have some precedent for overloading has* matchers, but I'll defer to Sam's judgement whether that's a good idea here.
Jun 8 2020
Jun 4 2020
Without jumping into the discussion whether it should be the default, I think we should be able to control template instantiation visitation separately from other implicit nodes.
Having to put AsIs on a matcher every time you need to match template instantiations is a rather big change (suddenly you have to change all the matchers you've written so far).
I love the idea of being able to control visitation of template instantiation.
I am somewhat torn on whether it should be the default, and would like to see more data.
I feel more strongly about needing AsIs when I want to match template instantiations.
May 27 2020
For the policy question: clang-format does intentionally not try to be stable - the "how to" suggestion for clang-format has always been to format changes lines and live with divergence (divergence from people manually formatting things is larger).
May 25 2020
May 20 2020
Given the extra complexity I'd like to see that it matters - bound nodes tend to be small.
May 19 2020
May 18 2020
May 13 2020
Update docs.
Rebase.
May 8 2020
Adding Sam, as I remember clangd having that problem.
Jan 28 2020
Jan 8 2020
Dec 2 2019
I'm not generally opposed to this, given that
a) clang-format already changes code; I think by now we're not fixing double semicolon mainly for workflow reasons, would be fine to add
b) the implementation is very self contained
Nov 25 2019
lg
generally makes sense
Oct 30 2019
Oct 24 2019
since resource directory should be picked relative
to the path of the clang-compiler in the compilation command.
Oct 23 2019
lg
Oct 21 2019
lg
Oct 17 2019
Oct 16 2019
Oct 15 2019
My intuitive solution would have been to get the char* for the start and end-location and then search forward and backwards for \n.
Oct 14 2019
Oct 11 2019
lg
Oct 10 2019
Oct 6 2019
Why not build a tool that takes the diff output of clang-format and changes it to what you want? Wouldn't that be a couple of lines of python?
Oct 2 2019
Sep 26 2019
LG, nice patch, thanks!
Sep 25 2019
Sep 24 2019
lg
Sep 18 2019
LG
LG. That makes lots of sense now :) Thanks!
Sep 17 2019
Sep 16 2019
LG
Sep 10 2019
Aug 20 2019
Yay, thanks!
Jul 25 2019
I am surprised this works as well as it does, but tests seem to indicate it does, so... LG (minus potentially reducing some duplication :)
Jul 24 2019
So, I did like the more exhaustive doc, I thought you'd move it to the code so it also shows up in the generated doc page :) (sorry for not being clearer here)
Jul 23 2019
LG, thx!
Jul 22 2019
Jul 8 2019
Jun 28 2019
LG
Jun 6 2019
LG