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.
