User Details
- User Since
- Jul 7 2012, 2:55 PM (568 w, 4 d)
- Roles
- Administrator
Apr 21 2023
Submitted.
Mar 30 2023
And thanks a lot for cleaning up, really appreciate it!
I apologize for not tagging appropriately - is that process documented somewhere?
Mar 23 2023
Thanks, yes, I did not intend to delete the else. This only triggers with fuzzing with rather involved inputs, thus I wasn't able to create a nice enough unit test.
I am so sorry, thanks for sending out the patch already and fixing the
layout!
Thank you!! Sorry for forgetting that I needed to do this, <shamecube>
Mar 6 2023
Answering the fundamental design question first.
Mar 3 2023
Remove superfluous include.
Mar 1 2023
Feb 27 2023
Feb 24 2023
Address review comments.
Address review comments.
Address review comments.
Feb 23 2023
Add comment.
Address reviewer comments.
Feb 16 2023
Feb 15 2023
Address review comments.
Feb 14 2023
Undo changes to ownership of initial set of FormatTokens.
Address reviewer comments.
Feb 1 2023
Jan 31 2023
And Ben already fixed it.
Working on a fix.
Nov 28 2022
For non-functional clean-ups generally llvm doesn't require pre-commit review - I did communicate here so people involved in the original change wouldn't miss the clean-up. I do agree that what commits to pre-review is a fine line, and usually try to err on the side of pre-review; I'll take your feedback into consideration for future changes.
Nov 26 2022
I changed it in 49aca00d63e14df8bc68fc4329e6cbc9c9805eb8.
Generally, why do we need to have that much information? I.e. why do we need to know the exact type of the "requires" keyword?
I do understand we need to know the brace type, but that seems like it would be easier to figure out in the TokenAnnotator (where we already parsed UnwrappedLines).
Do we ever parse UnwrappedLines differently depending on requires clauses/expressions?
If not, we should really do the annotation in TokenAnnotator, where we already have nice parsing bounds from the parsed UnwrappedLines.
Nov 25 2022
Hey ho, sorry for the late comment here, but adding peekNextToken(n) is problematic, as this gets in the way of future changes we want to do to handle macros better.
Usually we want to use X = Tokens->getPosition() and FormatTok = Tokens->setPosition(X) pairs when doing look-ahead.
I did a quick attempt at fixing this, but ran into infinite loops later in the annotator :(
Sep 21 2022
Jul 18 2022
Jul 12 2022
Jul 11 2022
Address review comments.
Jul 5 2022
Dec 1 2021
Nov 26 2021
Noticed I should have waiting with the renaming of the file until the review is done :( Sorry for the extra confusion.
Work in review comments.
Nov 24 2021
Thanks for cleaning up after me, and sorry for the mess - do y'all have clang-format set up as a presubmit or do you just remember to format manually?
Nov 22 2021
Nov 19 2021
Aug 9 2021
Feb 8 2021
Can you explain the change and the before/after a bit more? Thanks!
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