[PATCH] D29135: [libcxx] [test] Fix Clang -Wunused-local-typedef, part 1/3.

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

[libcxx] r294107 - Recommit [libcxx] Never use within libc++

Author: ericwf Date: Sat Feb 4 17:22:28 2017 New Revision: 294107 URL: http://llvm.org/viewvc/llvm-project?rev=294107=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

Re: Add warning for c++ member variable shadowing

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

[libcxx] r294106 - Fix inconsistency in tuple's SFINAE. Patch from Andrey Khalyavin"

Author: ericwf Date: Sat Feb 4 16:57:01 2017 New Revision: 294106 URL: http://llvm.org/viewvc/llvm-project?rev=294106=rev Log: Fix inconsistency in tuple's SFINAE. Patch from Andrey Khalyavin" Modified: libcxx/trunk/include/tuple Modified: libcxx/trunk/include/tuple URL:

[PATCH] D21279: Fix some issues in clang-format's AlignConsecutive modes

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

Re: Add warning for c++ member variable shadowing

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

[PATCH] D29550: Diagnose when "future_error(error_code)" constructor is called by user code

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

[libcxx] r294116 - Remove CMake hack

Author: ericwf Date: Sat Feb 4 19:19:02 2017 New Revision: 294116 URL: http://llvm.org/viewvc/llvm-project?rev=294116=rev Log: Remove CMake hack Modified: libcxx/trunk/CMakeLists.txt Modified: libcxx/trunk/CMakeLists.txt URL:

[PATCH] D24703: [clang-format] BreakBeforeBinaryOperations and AlignAfterOpenBracket conflict, bug 30304

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 ___

Re: Add warning for c++ member variable shadowing

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 > wrote: Hmm, now we're emitting one warning per path, it

[libcxx] r294115 - Fix typo in docs

Author: ericwf Date: Sat Feb 4 19:16:25 2017 New Revision: 294115 URL: http://llvm.org/viewvc/llvm-project?rev=294115=rev Log: Fix typo in docs Modified: libcxx/trunk/docs/DesignDocs/DebugMode.rst Modified: libcxx/trunk/docs/DesignDocs/DebugMode.rst URL:

Re: Add warning for c++ member variable shadowing

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 ,

Re: Add warning for c++ member variable shadowing

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

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. 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

[PATCH] D29557: [clang-tools-extra] Fix pthread link

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

Re: Add warning for c++ member variable shadowing

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

[libcxx] r294103 - Merge r294099 - Undefine min/max in __tree

Author: ericwf Date: Sat Feb 4 16:36:27 2017 New Revision: 294103 URL: http://llvm.org/viewvc/llvm-project?rev=294103=rev Log: Merge r294099 - Undefine min/max in __tree Added: libcxx/branches/release_40/test/libcxx/containers/associative/undef_min_max.pass.cpp Modified:

Re: Add warning for c++ member variable shadowing

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

Re: [libcxx] r294099 - Undefine min/max in __tree

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 < >

Re: [clang-tools-extra] r291892 - Fix the build of the include-fixer plugin for some shared cmake builds and MSVC.

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

Re: r293065 - Clarify how to forward-declare __llvm_profile symbols.

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=rev > Log: > Clarify how to forward-declare __llvm_profile

[PATCH] D29151: [clang-tidy] Add misc-invalidated-iterators check.

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

[PATCH] Improved plugin/tool support by expanding an existing attribute

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

[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

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

[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

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

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

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

[PATCH] D29267: [clang-tidy] safety-no-assembler

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

[PATCH] D29267: [clang-tidy] safety-no-assembler

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:

[PATCH] D29393: [clang-tidy] Don't warn about call to unresolved operator*

idlecode added inline comments. Comment at: clang-tidy/misc/UnconventionalAssignOperatorCheck.cpp:63 +cxxOperatorCallExpr(argumentCountIs(1), +callee(unresolvedLookupExpr()), +hasArgument(0,

[libcxx] r294100 - Mark basic_string::assign templates as inline to improve ABI stability.

Author: ericwf Date: Sat Feb 4 14:38:35 2017 New Revision: 294100 URL: http://llvm.org/viewvc/llvm-project?rev=294100=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 the

[PATCH] D29542: [TargetInfo] Adjust x86-32 atomic support to the CPU used

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

[PATCH] D28346: [AVR] Allow specifying the CPU on the command line

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

[PATCH] D28344: [AVR] Add support for the full set of inline asm constraints

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

[PATCH] D29545: Driver: Do not link safestack with --whole-archive.

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 ===

[PATCH] D28235: [clang-format cleanup] merge continuous deleted lines into one deletion.

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

[PATCH] D28235: [clang-format cleanup] merge continuous deleted lines into one deletion.

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

[PATCH] D29542: [TargetInfo] Adjust x86-32 atomic support to the CPU used

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

[PATCH] D29542: [TargetInfo] Adjust x86-32 atomic support to the CPU used

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

[PATCH] D29542: [TargetInfo] Adjust x86-32 atomic support to the CPU used

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

[libcxx] r294099 - Undefine min/max in __tree

Author: ericwf Date: Sat Feb 4 14:27:46 2017 New Revision: 294099 URL: http://llvm.org/viewvc/llvm-project?rev=294099=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:

Re: [libcxx] r294099 - Undefine min/max in __tree

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: