- User Since
- Dec 27 2014, 8:52 PM (168 w, 6 d)
Thu, Mar 22
@rtrieu gentle ping!
Sun, Mar 18
@rtrieu ping! I've rebased this on the pure refactoring you committed for me last week.
Thu, Mar 15
Wed, Mar 14
Boldly add -Wreturn-std-move to -Wmove (and thus also to -Wall).
The backward-compatibility-concerned diagnostic, -Wreturn-std-move-in-c++11, is *not* appropriate for -Wmove; but I believe this main diagnostic is appropriate.
Tue, Mar 13
@rtrieu thanks! I don't have commit privileges; could I ask you to commit this on my behalf? (Or if not, please say no, and I'll know to go looking for someone else to ask.)
Sat, Mar 10
Addressed @rtrieu's comments.
Fri, Mar 9
Wed, Mar 7
Btw, I'm going to be talking about this patch tonight at 7 in Palo Alto. :)
Tue, Mar 6
Mon, Mar 5
Fri, Mar 2
@rtrieu please take a look?
Thu, Mar 1
Wed, Feb 28
Rename some functions and parameters. Rebase onto D43898.
Add a block comment for function TryMoveInitialization.
Mon, Feb 26
@rtrieu please take a look?
Fri, Feb 23
Thu, Feb 22
Eliminate a couple of auto per comment by @Rakete1111.
Feb 19 2018
Removed a redundant check for LValueReferenceType in the CWG1579 codepath. (In that branch, we know that standard C++ *did* perform the copy-to-move transformation, so obviously we can't have had an lvalue reference type originally.) I've verified that the check is still needed (not redundant) along the other codepath.
@rsmith and/or @rtrieu, please take another look? All my TODOs are done now: there are fixits, and the wording of the diagnostic changes if it's a "throw" instead of a "return", and the wording has been updated per Richard Smith's suggestions.
Feb 16 2018
Feb 15 2018
Reword the diagnostic per rsmith's suggestions.
- figure out how to detect whether this is a return-stmt or throw-expression
- figure out how to generate the appropriate fixit
Feb 14 2018
Feb 3 2018
Jan 31 2018
Jan 30 2018
Jan 25 2018
FWIW, I would also like this patch, because it would mean that I could build with -Werror even when the project includes headers written by MSVC-using people. Given that we know what "#pragma region" does, it hardly deserves an "unknown pragma" diagnostic! So this patch is great IMHO. :)
Jan 4 2018
Jan 2 2018
@weimingz: Since your platform supports srand(0), is it possible to look at how your platform implements srand(0) and "inline" that implementation into random_device? That seems like it would be more in keeping with the other ifdefs in this file.
Dec 16 2017
I keep seeing patches go by for other targets where they're just implementing random_device for their target. It doesn't *have* to be based on an actual /dev/urandom. You can see all the other options under #ifdefs in this file: getentropy, /dev/random, nacl_secure_random, arc4random, rand_s,... If you're on a target that doesn't have any of these, then IMO the appropriate patch would be one of
Dec 13 2017
Nov 16 2017
Oct 9 2017
I'm also much out of my depth here, but I'm skeptical. You're changing the comments in the code from essentially saying "This workaround helps people with broken code" to essentially saying "This indispensable functionality helps people like me who use dlopen()." Are you 100% sure that you're not just a person with broken code?
Sep 18 2017
Sep 17 2017
Sep 13 2017
Sep 12 2017
Sep 11 2017
TODO.txt says "future should use <atomic> for synchronization." I would have interpreted this as meaning that the line
Aug 8 2017
Aug 3 2017
I've updated D35863 to be actually correct AFAICT from my local testing; but I'm not sure what's the most appropriate way to get "fancy allocator" tests into libcxx's test suite. The way I did it locally is here:
Basically, I conditionally replace "test_allocator.h" with "test_fancy_allocator.h", and then re-run all the existing tests. "test_fancy_allocator" uses fancy pointers that carry with them a "payload" of the allocated size n, and then in a.deallocate(p,n) we assert that p.payload()==n. A bunch of list tests fail this assertion before this patch, and none fail after this patch.
Jul 28 2017
But if I'm overseeing reasons to issue a warning in this case, we could add an analogue of -Wshadow-uncaptured-local for this case. WDYT?
Jul 25 2017
Jul 18 2017
If the goal is fine-grained control over the heuristics for compiling switch statements, perhaps one should enumerate all the possible ways to lower switch statements --- jump-tables, lookup-tables, if-trees, if-chains, (more?) --- and add a separate flag for each of them.
...Although I'm not sure what purpose there'd really be in saying "This switch statement *must* be compiled into an if-else tree" or "this one *must* be a lookup table"; couldn't that end up being a pessimization one day, as the optimizer gets smarter?
Jun 26 2017
Mar 27 2017
Mar 10 2017
I notice that the Standard implies that std::unique_ptr<T> will work only with *object types* T, and yet the "object" wording is missing from shared_ptr.
Jan 11 2017
Jan 10 2017
Dec 29 2016
Dec 26 2016
PVS-Studio implements tons of checks of this variety. See e.g.
They don't have a catchy name for the category either, but perhaps "suspicious-" or "copypaste-" would do.
Dec 16 2016
The provided example (typoing "i" for "j") sounds like the sort of thing that PVS-Studio catches; maybe see what wording they use for that kind of mistake? Without investigating, I would suggest "cut-and-paste-error" or "likely-typo".
Dec 15 2016
LGTM. I wonder if rsmith is happy with the exact semantics of "shouldUseUndefinedBehaviorReturnOptimization"... but that seems like a tiny nit that's fixable post-commit anyway.
Nov 28 2016
Sep 8 2016
Jul 19 2016
May 5 2016
It seems like this proposed diagnostic and fixit, statistically speaking, is *never* correct.
In the cases where there is a code issue to be corrected, the diagnosable issue really seems to involve dataflow analysis:
Apr 15 2016
I would like to see a new version of http://reviews.llvm.org/D19105 with all the "1-bit-bitfield" diffs removed.
Right now, it's hard to see that there's *anything* in D19105 that's not a miscorrection of a 1-bit bitfield.
Apr 16 2015
Dec 28 2014
Dec 27 2014
Commented on a test. The functional change is way out of my league.
Also consider adding a "three-pass" test case similar to