It would be awesome if this kind of shadowing warning could be put into
-Wall. My recollection on the last set of -Wshadow reviews is that most
shadowing warnings are from ctor arguments being used to initialize
members. Here's the last discussion / review regarding shadowing
http://reviews.l
Maybe we should add a new warning in Clang for this. -Wshadow diagnosis's
this but -Wshadow isn't a part of -Wall or -Wextra so it's of limited
utility.
A separate warning for shadowing 'x' caused by "T(x)" might be useful.
Do people actually use "T(x)" in the wild to default construct 'x'?
/Eric
Makes sense. Here's hoping parameter deduction for constructors makes
it in!
(better link)
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0091r2.html
On 6/15/2016 1:54 PM, Eric Fiselier wrote:
I've had a change of heart. I think that lock_guard<> has some utility
in generic code, a
I've had a change of heart. I think that lock_guard<> has some utility in
generic code, and I'm not sure removing it is a good idea. For example a
function like:
template
void ExecuteUnderLocks(Func&& fn, Locks&... locks) {
lock_guard g(locks...);
fn();
}
I checked the proposal and it's clea
On 6/15/2016 1:15 PM, Eric Fiselier wrote:
On Wed, Jun 15, 2016 at 11:45 AM, Craig, Ben via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
Does this change (and the paper) permit declarations like the
following?
lock_guard<> guard();
If that syntax is allowed, then
On Wed, Jun 15, 2016 at 11:45 AM, Craig, Ben via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Does this change (and the paper) permit declarations like the following?
>
> lock_guard<> guard();
>
> If that syntax is allowed, then this is also likely allowed...
>
> lock_guard<>(guard);
Does this change (and the paper) permit declarations like the following?
lock_guard<> guard();
If that syntax is allowed, then this is also likely allowed...
lock_guard<>(guard);
I would really like the prior two examples to not compile. Here is a
common bug that I see in the wild...
Update on the bot failures:
I've spoken to the owner of the bots and they are planning to upgrade their
Clang versions.
This will get the bots green again.
/Eric
On Mon, Jun 13, 2016 at 11:49 PM, Eric Fiselier wrote:
> This is causing some of the libc++ bots to go red.
> `variadic_copy.fail.cp
This is causing some of the libc++ bots to go red. `variadic_copy.fail.cpp`
is encountering an error, which seems to be a clang bug which temporarily
existed in 3.9.
The test passes against current ToT and older clang releases and GCC.
Please do not revert this commit due to that specific failure.
Author: ericwf
Date: Mon Jun 13 22:48:09 2016
New Revision: 272634
URL: http://llvm.org/viewvc/llvm-project?rev=272634&view=rev
Log:
Implement variadic lock_guard.
Summary:
This patch implements the variadic `lock_guard` paper.
Making `lock_guard` variadic is a ABI breaking change because the
10 matches
Mail list logo
