idlecode added inline comments.
Comment at: clang-tidy/misc/UnconventionalAssignOperatorCheck.cpp:63
+cxxOperatorCallExpr(argumentCountIs(1),
+callee(unresolvedLookupExpr()),
+hasArgument(0, cxxThisExpr()
mgorny added a comment.
In https://reviews.llvm.org/D28213#666269, @dim wrote:
> > What's the value of `__atomic_always_lock_free(sizeof(long long), 0)` for
> > gcc and clang?
>
> For gcc, it is always 0, for clang (I tested 3.4.1 through 4.0.0) it is
> always 1. Maybe that was always incorrec
asl requested changes to this revision.
asl added inline comments.
This revision now requires changes to proceed.
Comment at: lib/Driver/MinGWToolChain.cpp:211
+#ifndef LLVM_ON_WIN32
if (GetRuntimeLibType(DriverArgs) == ToolChain::RLT_Libgcc) {
This check is
idlecode added inline comments.
Comment at: clang-tools-extra/docs/clang-tidy/checks/list.rst:156
+ safety-no-assembler
+ safety-no-vector-bool
`safety-no-vector-bool` seems to belong to the other patch.
Comment at: clang-tools-extra/test/c
jbcoe planned changes to this revision.
jbcoe added inline comments.
Comment at: clang-tools-extra/test/clang-tidy/safety-no-assembler.cpp:2
+// RUN: %check_clang_tidy %s safety-no-assembler %t
+
+void f() {
idlecode wrote:
> Maybe this check should handle `FileS
dim added a comment.
Created https://llvm.org/bugs/show_bug.cgi?id=31864 to continue this on the bug
tracker.
Repository:
rL LLVM
https://reviews.llvm.org/D28213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-b
Many plugins/tools could benefit from having a generic way for communicating
control directives directly from the source code to itself (via the AST) when
acting, for example, as source code transformers, generators, collectors and
the like. Attributes are a suitable way of doing this but most a
Prazek added a comment.
In https://reviews.llvm.org/D29151#665948, @alexfh wrote:
> In https://reviews.llvm.org/D29151#662504, @zaks.anna wrote:
>
> > Before clang-tidy came into existence the guidelines were very clear. One
> > should write a clang warning if the diagnostic:
> >
> > - can be im
idlecode added inline comments.
Comment at: lib/Format/Format.cpp:1182
+ I != E; ++I)
+ LastToNextLineFirst[(*I)->Last] = (*std::next(I))->First;
tooling::Replacements Fixes;
Could you add brackets around loop body?
Comment at
idlecode requested changes to this revision.
idlecode added a comment.
This revision now requires changes to proceed.
Few other tests (from `ChangeNamespaceTest`) require update too.
https://reviews.llvm.org/D28235
___
cfe-commits mailing list
cfe-c
mgorny created this revision.
Herald added a subscriber: emaste.
Set the maximum width of atomic operations on x86-32 based on the target
CPU. The 64-bit inline atomics require cmpxchg8b which is an i586
instruction. Other inline atomics require cmpxchg which is an i486
instruction.
This fixes th
jlebar added a comment.
> Could someone help me figure out what is the cause and correct solution to
> that failure? @jlebar?
The test is checking that the macros have the same value when compiling for
CUDA host and device. That is, if we're compiling for an x86 CPU and an NVPTX
GPU, we invok
dim added inline comments.
Comment at: lib/Basic/Targets.cpp:4244
+} else // allow locked atomics up to 4 bytes
+ MaxAtomicPromoteWidth = 32;
+ }
Are you purposefully not setting `MaxAtomicInlineWidth` here? (It seems from
`TargetInfo` that the defaul
Author: ericwf
Date: Sat Feb 4 14:27:46 2017
New Revision: 294099
URL: http://llvm.org/viewvc/llvm-project?rev=294099&view=rev
Log:
Undefine min/max in __tree
Added:
libcxx/trunk/test/libcxx/containers/associative/undef_min_max.pass.cpp
Modified:
libcxx/trunk/include/__tree
Modified: li
I'm going to merge this into v4.0 in order to fix
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216772
/Eric
On Sat, Feb 4, 2017 at 1:27 PM, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ericwf
> Date: Sat Feb 4 14:27:46 2017
> New Revision: 294099
>
> URL: ht
mgorny added a comment.
In https://reviews.llvm.org/D29542#666831, @jlebar wrote:
> > Could someone help me figure out what is the cause and correct solution to
> > that failure? @jlebar?
>
> You can see in NVPTXTargetInfo that we read properties from the host
> targetinfo so that we export the
Author: ericwf
Date: Sat Feb 4 14:38:35 2017
New Revision: 294100
URL: http://llvm.org/viewvc/llvm-project?rev=294100&view=rev
Log:
Mark basic_string::assign templates as inline to improve ABI stability.
Visible definitions for basic_string::assign are sometimes emitted in
the dylib depending on
asl added inline comments.
Comment at: test/CodeGen/avr/target-cpu-defines/atmega328p.c:1
+// RUN: %clang_cc1 -triple avr-unknown-unknown -target-cpu atmega328p
-emit-llvm %s -o - | FileCheck %s
+
This looks wrong. How you're using FileCheck? Consider dumping pr
asl added inline comments.
Comment at: test/CodeGen/avr-inline-asm-constraints.c:2
+// REQUIRES: avr-registered-target
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s | FileCheck
%s
+
You need checks for multi-character stuff and unsupported c
pcc created this revision.
This allows it to be used with the other sanitizers.
https://reviews.llvm.org/D29545
Files:
clang/lib/Driver/Tools.cpp
clang/test/Driver/sanitizer-ld.c
Index: clang/test/Driver/sanitizer-ld.c
===
--
EricWF created this revision.
The constructor `future_error(error_code)` isn't part of the C++ standard, but
libc++ provides it in order to construct `future_error`'s before C++17.
However since it's non-standard we probably shouldn't be providing it all. We
could make the constructor private bu
Author: ericwf
Date: Sat Feb 4 16:36:27 2017
New Revision: 294103
URL: http://llvm.org/viewvc/llvm-project?rev=294103&view=rev
Log:
Merge r294099 - Undefine min/max in __tree
Added:
libcxx/branches/release_40/test/libcxx/containers/associative/undef_min_max.pass.cpp
Modified:
libcxx/bra
Merged in r294103.
On Sat, Feb 4, 2017 at 1:39 PM, Eric Fiselier wrote:
> I'm going to merge this into v4.0 in order to fix
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216772
>
> /Eric
>
> On Sat, Feb 4, 2017 at 1:27 PM, Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote
EricWF added a comment.
Since all of these changes are for libc++ specific tests I would much rather
see changes of this form:
#if defined(_LIBCPP_VERSION)
{
typedef foo bar;
static_assert(baz, "");
}
#endif
I think that's a lot nicer than wrapping every statement in the block i
EricWF accepted this revision.
EricWF added inline comments.
This revision is now accepted and ready to land.
Comment at: test/std/utilities/utility/pairs/pairs.pair/default.pass.cpp:52
using P2 = std::pair;
-static_assert(!std::is_default_constructible::value, "
Author: ericwf
Date: Sat Feb 4 16:57:01 2017
New Revision: 294106
URL: http://llvm.org/viewvc/llvm-project?rev=294106&view=rev
Log:
Fix inconsistency in tuple's SFINAE. Patch from Andrey Khalyavin"
Modified:
libcxx/trunk/include/tuple
Modified: libcxx/trunk/include/tuple
URL:
http://llvm.o
Author: ericwf
Date: Sat Feb 4 17:22:28 2017
New Revision: 294107
URL: http://llvm.org/viewvc/llvm-project?rev=294107&view=rev
Log:
Recommit [libcxx] Never use within libc++
It is my opinion that libc++ should never use ``, including in the
`dylib`.
This patch remove all uses of `assert` from
Author: ericwf
Date: Sat Feb 4 19:16:25 2017
New Revision: 294115
URL: http://llvm.org/viewvc/llvm-project?rev=294115&view=rev
Log:
Fix typo in docs
Modified:
libcxx/trunk/docs/DesignDocs/DebugMode.rst
Modified: libcxx/trunk/docs/DesignDocs/DebugMode.rst
URL:
http://llvm.org/viewvc/llvm-pr
Author: ericwf
Date: Sat Feb 4 19:19:02 2017
New Revision: 294116
URL: http://llvm.org/viewvc/llvm-project?rev=294116&view=rev
Log:
Remove CMake hack
Modified:
libcxx/trunk/CMakeLists.txt
Modified: libcxx/trunk/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists
daphnediane added a comment.
In https://reviews.llvm.org/D21279#663670, @bmharper wrote:
> Thanks - the merge conflicts don't look too bad. I should have it cleaned up
> by tomorrow.
Have you had a chance to do the merge yet? If not I have a merged version which
passes the tests that I could
Thanks Richard! Good catch! The updated version is attached. --James
From: on behalf of Richard Smith
Date: Thursday, February 2, 2017 at 11:59 AM
To: James Sun
Cc: Saleem Abdulrasool , "cfe-commits@lists.llvm.org"
, Aaron Ballman
Subject: Re: Add warning for c++ member variable shadowing
Th
daphnediane added a comment.
ping. I've been using this for a long time and still seems to apply to cleanly
and works, though the line numbers have shifted a little since I generated the
previous diff.
https://reviews.llvm.org/D24703
___
cfe-commi
Hmm, now we're emitting one warning per path, it looks like we might
diagnose shadowing the same field more than once (for a repeated
non-virtual base class). Is that intentional? Maybe we should just skip
producing the warning if the lookup would be ambiguous, since any use of
the shadowed field w
Don't we have a map to prevent this? I think the unit test does have cases to
cover ambiguous paths to the same base. --J
Sent from my iPhone
On Feb 4, 2017, at 6:22 PM, Richard Smith
mailto:rich...@metafoo.co.uk>> wrote:
Hmm, now we're emitting one warning per path, it looks like we might dia
Hi Ben,
This change doesn't work when doing out-of-tree builds since `PTHREAD_LIB`
is defined by LLVM's `config-ix.cmake` and
therefore isn't defined during out-of-tree builds. It looks like the
pthread configuration needs to be lifted out of LLVM's
`config-ix.cmake` and placed somewhere the insta
Ok I get your point. Suppose there are two paths from class B to base class A.
One is with access as_none; the other is as_public. Then there is a chance that
the as_none path is recorded and the as_public one is skipped. In this case we
should give the warning as well. Should be easy to fix wit
EricWF created this revision.
Herald added a subscriber: mgorny.
This patch contains the clang-tools-extra changes required by
https://reviews.llvm.org/D29555
https://reviews.llvm.org/D29557
Files:
include-fixer/plugin/CMakeLists.txt
Index: include-fixer/plugin/CMakeLists.txt
=
updated
From: James Sun
Date: Saturday, February 4, 2017 at 6:52 PM
To: Richard Smith
Cc: Saleem Abdulrasool , "cfe-commits@lists.llvm.org"
, Aaron Ballman
Subject: Re: Add warning for c++ member variable shadowing
Ok I get your point. Suppose there are two paths from class B to base class A.
Thanks!
On Wed, Jan 25, 2017 at 8:01 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: nico
> Date: Wed Jan 25 10:01:32 2017
> New Revision: 293065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293065&view=rev
> Log:
> Clarify how to forward-declare __llvm_profile s
oops
From: James Sun
Date: Saturday, February 4, 2017 at 9:19 PM
To: Richard Smith
Cc: Saleem Abdulrasool , "cfe-commits@lists.llvm.org"
, Aaron Ballman
Subject: Re: Add warning for c++ member variable shadowing
updated
From: James Sun
Date: Saturday, February 4, 2017 at 6:52 PM
To: Richard
Thanks, just one more thing I noticed (sorry!) and this looks good to go.
+def warn_shadow_field : Warning<
+ "non-static data member '%0' of '%1' shadows member inherited from type
'%2'">,
+ InGroup;
-Wshadow-ivar doesn't really make sense for this; that's for an Objective-C
feature. A new -W
Thanks Richard! Hopefully this is the last patch :D
Could you please help me to commit it maybe?
Thanks
James
From: on behalf of Richard Smith
Date: Saturday, February 4, 2017 at 10:43 PM
To: James Sun
Cc: Saleem Abdulrasool , "cfe-commits@lists.llvm.org"
, Aaron Ballman
Subject: Re: Add wa
42 matches
Mail list logo
