- User Since
- Feb 12 2020, 7:33 AM (50 w, 7 h)
Most of these clang-tidy errors are from a mismatch between gRPC naming conventions and ours, I'm going to keep it as the gRPC ones because that's what we do elsewhere unless there are any objections.
Mon, Jan 25
Yep, it is not designed for that and I added a warning in the documentation.
Sun, Jan 24
Sat, Jan 23
Removed redundant third function register_requires, it may become necessary later but it isn't now.
Sat, Jan 9
Update CommandLineReference.rst to also include -fno-finite-loops
while(1) case was mishandled for C++11 onwards, fixed now.
Fri, Jan 8
Thu, Jan 7
I'm happy to add a patch amending this, the reason it wasn't done that way was because at the time and even now, out of icc/clang/msvc/gcc, gcc seems to be the only one that happily removed such loops in C++ (https://godbolt.org/z/W9vj99), and I didn't have a particularly strong opinion on which way we should lean at the time.
Thu, Dec 31
Ah I see, I was never able to find clear documentation on what exactly the -cc1 flag does other than the conceptual description. This should fix it right?
Wed, Dec 30
I can't say that I know with any certainty, I'm too inexperienced. This failure was missed by me locally, the pre-merge bot, and by most of the buildbots other than the ones I mentioned above. I have no idea under what configuration of CMake options will clang not emit this particular case of a label for a BB.
Dec 23 2020
Yep, sorry, I'm just waiting for a final stamp of approval from one of the reviewers.
As expected, @fhahn was right, adding willreturn to all those tests was an artifact from previous revisions of this patch and it passed the tests so I didn't pay them any mind, but I removed them now.
Dec 22 2020
Dec 16 2020
Updated commit message, sanity ping for pre-merge buildbot.
Dec 15 2020
Added debug messages for when the new calls fail.
Addresses inline comments (partially, fixing).
Nov 30 2020
Nov 29 2020
I believe this happened becase when I removed the loop, I did not update MemorySSA. The exact error was from GVN, but this update seems to fix the stage 2 build compile time error locally (I checked by running the build bot script).
This introduced a compile-time error that showed up during a stage 2 build.
Nov 9 2020
Nov 6 2020
I'm so sorry, I saw that you fixed it, thank you.
I naively assumed that reverting it would be fine, I'm working on a fixing right now.
- Fixed failing test
Nov 5 2020
removed non-parent revision.
using buildkite recommended fix
- Addressed nits
- Final Pre-commit testing
Nov 4 2020
Nov 3 2020
Hopefully the unrelated hwasan test failure is now fixed on master, trying again.
Nov 2 2020
ignore, testing pre-build bots again.
- Added triple to fix mangling errors in test
- Modified (unrelated) recently added test to have the mustprogress attribute
- Updated title, revision summary, and commit message
- Added documentation for struct and members
Nov 1 2020
Oct 30 2020
Oct 29 2020
Thank you for the comments. I think I follow, I'll post another less intrusive patch soon.
Oct 25 2020
- Adds test.
- Uses getExitBlocks() instead of getUniqueExitBlocks() and moved definition.
- Changed definition of hasNoExitBlocks() to use empty() instead of conditional
- Style changes in deleteDeadLoop for readibility.
Added word back in.
Add parent revision for buildkite.
Oct 21 2020
Oct 20 2020
Oct 19 2020
Sorry, I understand now. Is this more correct?
Oct 18 2020
Oct 16 2020
Reverted to prior diff.
Oct 14 2020
I think that phrase ("w/o maxobjsize deduction") could be a bit misleading, IINM, when @jdoerfert says w/o maxobjsize deduction he means without having the functionality built into the attributor to update the maximum object size estimate. So in the patch D87975, there's a crude over-approximation for the maxobjsize (getPointerMaxObjSize) and the numbers are for just using that over-approximation without including the changes in D87978 that refine it, so we would still need the maxobjsize attribute first in order to do this.