Re: [PATCH] D24469: [clang-cl] Diagnose duplicate uuids.

thakis closed this revision. thakis added a comment. r281367, thanks! https://reviews.llvm.org/D24469 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r281375 - Add some MS aliases for existing intrinsics

This breaks building Chromium, https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin64%28dbg%29/builds/7125/steps/compile/logs/stdio FAILED: obj/components/webcrypto/webcrypto/aes_gcm.obj ../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo /showIncludes /FC @obj/componen

Re: r281395 - Try harder to not inline dllimport functions referencing non-dllimport functions

Could other implicit functions (operator=, ctors) have similar issues? On Tue, Sep 13, 2016 at 5:08 PM, Hans Wennborg via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: hans > Date: Tue Sep 13 16:08:20 2016 > New Revision: 281395 > > URL: http://llvm.org/viewvc/llvm-project?rev=281395

r281430 - Follow-up to r281367: Compare uuids case-insensitively.

Author: nico Date: Tue Sep 13 20:16:54 2016 New Revision: 281430 URL: http://llvm.org/viewvc/llvm-project?rev=281430&view=rev Log: Follow-up to r281367: Compare uuids case-insensitively. Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp cfe/trunk/test/SemaCXX/ms-uuid.cpp Modified: cfe/trunk/

Re: r281452 - Revert "[modules] When merging one definition into another, propagate the list of re-exporting modules from the discarded definition to the retained definition."

When reverting something, please say why in the commit message. On Sep 14, 2016 6:13 AM, "Eric Liu via cfe-commits" < cfe-commits@lists.llvm.org> wrote: > Author: ioeric > Date: Wed Sep 14 05:05:10 2016 > New Revision: 281452 > > URL: http://llvm.org/viewvc/llvm-project?rev=281452&view=rev > Log:

Re: [PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

thakis added a comment. Works for me if rnk likes it :-) (We could bikeshed on if this should be one of the -Wmicrosoft warnings, but the warning can't be both in -Wall and -Wmicrosoft, so let's don't). I do have a question about the test (the first commit below): Comment at:

Re: [PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

thakis added inline comments. Comment at: test/SemaCXX/warn-msvc-enum-bitfield.cpp:12 @@ +11,3 @@ + + s.e2 = E2; + s.f2 = F2; sashab wrote: > thakis wrote: > > Shouldn't this be the version that warns? The assignment with E1 assigns 0 > > which is portable, but

Re: r297861 - Don't use MSVC Setup Api on MinGW.

Should this be a compile-time thing? I thought in general we try to make clang-built-with-msvc and clang-built-with-mingw behave roughly the same except for a different default triple, i.e. maybe this should be keyed off the triple at runtime instead of with a compile-time ifdef. Or do some of the

Re: r299204 - clang-format: [JavaScript] Ignore QT keywords.

Please use style.isCpp() (spelling?) instead of comparing with LK_Cpp and LK_ObjC. On Mar 31, 2017 8:17 AM, "Daniel Jasper via cfe-commits" < cfe-commits@lists.llvm.org> wrote: Author: djasper Date: Fri Mar 31 07:04:37 2017 New Revision: 299204 URL: http://llvm.org/viewvc/llvm-project?rev=299204

Re: r299214 - clang-format: Fix post-commit review comment of r299204, use Style.isCpp().

Thanks! On Fri, Mar 31, 2017 at 9:30 AM, Daniel Jasper via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: djasper > Date: Fri Mar 31 08:30:24 2017 > New Revision: 299214 > > URL: http://llvm.org/viewvc/llvm-project?rev=299214&view=rev > Log: > clang-format: Fix post-commit review comm

r299574 - clang-format: Support formatting utf-8 character literals in C++11+ mode.

Author: nico Date: Wed Apr 5 13:10:42 2017 New Revision: 299574 URL: http://llvm.org/viewvc/llvm-project?rev=299574&view=rev Log: clang-format: Support formatting utf-8 character literals in C++11+ mode. clang-format

r299952 - [clang-format] Recognize Java logical shift assignment operator

Author: nico Date: Tue Apr 11 10:50:04 2017 New Revision: 299952 URL: http://llvm.org/viewvc/llvm-project?rev=299952&view=rev Log: [clang-format] Recognize Java logical shift assignment operator At present, clang-format mangles Java containing logical right shift operators ('>>>=' or '>>>'), spl

Re: [libcxx] r300411 - Workaround Clang bug regarding template template parameters

Is that bug filed? On Sat, Apr 15, 2017 at 10:47 PM, Eric Fiselier via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: ericwf > Date: Sat Apr 15 21:47:46 2017 > New Revision: 300411 > > URL: http://llvm.org/viewvc/llvm-project?rev=300411&view=rev > Log: > Workaround Clang bug regarding

Re: r291783 - UsersManual.rst: Update clang-cl options list

Why do we list fdelayed-template-parsing in /? output now? That's on by default with clang-cl. On Thu, Jan 12, 2017 at 1:15 PM, Hans Wennborg via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: hans > Date: Thu Jan 12 12:15:06 2017 > New Revision: 291783 > > URL: http://llvm.org/viewvc

Re: r291783 - UsersManual.rst: Update clang-cl options list

Also, it looks like the main change is that this now lists /execution-charset: and /source-charset:. It doesn't list /utf-8 though (since that's just a CLIgnoredFlag behind the scenes I guess). It's a bit weird to list the two -charset flags (which just check that their arg is utf-8 and error out i

Re: r291905 - [Sema] Add warning for unused lambda captures

This warns about code like constexpr int foo = 4; [&foo]() { use(foo); } That's correct, but removing &foo then makes MSVC complain about this code like "error C3493: 'foo' cannot be implicitly captured because no default capture mode has been specified". A workaround is to make foo static co

Re: [libcxx] r291961 - Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.

This happens to fire in practice in protobuf. It's probably a true positive and it's cool that this warning found it, but it means we have to disable Wuser-defined-warnings for a bit -- which then disables all of these user-defined warnings. Right now there aren't any others, but it feels like we'd

Re: r291905 - [Sema] Add warning for unused lambda captures

On Sun, Jan 22, 2017 at 6:17 AM, Malcolm Parsons wrote: > On 20 January 2017 at 21:32, Nico Weber wrote: > > This warns about code like > > > > constexpr int foo = 4; > > [&foo]() { use(foo); } > > > > That's correct, but removing &foo then makes MSVC complain about this > code > > like "err

Re: r291905 - [Sema] Add warning for unused lambda captures

On Mon, Jan 23, 2017 at 5:29 PM, Aaron Ballman wrote: > On Mon, Jan 23, 2017 at 5:00 PM, Nico Weber via cfe-commits > wrote: > > On Sun, Jan 22, 2017 at 6:17 AM, Malcolm Parsons < > malcolm.pars...@gmail.com> > > wrote: > >> > >> On 20 January 2017 a

r293065 - Clarify how to forward-declare __llvm_profile symbols.

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 symbols. Modified: cfe/trunk/docs/SourceBasedCodeCoverage.rst Modified: cfe/trunk/docs/SourceBasedCodeCoverage.rst

Re: [libcxx] r290889 - [libcxx] Add build/test support for the externally threaded libc++abi variant

This breaks all our mac builds with: /b/c/b/ClangToTMac__dbg_/src/third_party/llvm-build/Release+Asserts/bin/../include/c++/v1/__threading_support:154:1: error: unknown type name 'mach_port_t' mach_port_t __libcpp_thread_get_port(); On Tue, Jan 3, 2017 at 7:59 AM, Asiri Rathnayake via cfe-commits

Re: [libcxx] r290889 - [libcxx] Add build/test support for the externally threaded libc++abi variant

Is it intentional that this change affects non-LIBCXX_HAS_EXTERNAL_THREAD_API builds at all? On Wed, Jan 25, 2017 at 12:31 PM, Nico Weber wrote: > This breaks all our mac builds with: > > /b/c/b/ClangToTMac__dbg_/src/third_party/llvm-build/ > Release+Asserts/bin/../include/c++/v1/__threading_sup

Re: [libcxx] r290889 - [libcxx] Add build/test support for the externally threaded libc++abi variant

> On 25 Jan 2017 5:52 p.m., "Asiri Rathnayake" > wrote: > >> (including cfe-commits) >> >> On Wed, Jan 25, 2017 at 5:51 PM, Asiri Rathnayake < >> asiri.rathnay...@gmail.com> wrote: >> >>> Hi Nico, >>> >>> On Wed, Jan 25,

Re: [libcxx] r290889 - [libcxx] Add build/test support for the externally threaded libc++abi variant

iri.rathnay...@gmail.com> wrote: >>> >>>> @Nico: could you let me know your build configuration? (cmake options) >>>> >>>> I'm surprised this went unnoticed for so long. >>>> >>>> Thanks. >>>> >>>> / A

r293675 - Keep Chromium ObjC column limit at 80 for consistency with C++

Author: nico Date: Tue Jan 31 12:42:05 2017 New Revision: 293675 URL: http://llvm.org/viewvc/llvm-project?rev=293675&view=rev Log: Keep Chromium ObjC column limit at 80 for consistency with C++ https://reviews.llvm.org/D29337 Patch from Dan Beam ! Modified: cfe/trunk/lib/Format/Format.cpp M

[libunwind] r306442 - [libunwind] Add _LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS

Author: nico Date: Tue Jun 27 11:37:06 2017 New Revision: 306442 URL: http://llvm.org/viewvc/llvm-project?rev=306442&view=rev Log: [libunwind] Add _LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS It's useful to be able to disable visibility annotations entirely; for example, if we're building libunwind

Re: r307175 - [Sema] Don't allow -Wunguarded-availability to be silenced with redecls

We currently rely on this for chromium; that's how the warning used to work when I added it. What's the transition plan? Can we have a flag to incrementally transition to whatever the new way is? (Is it documented anywhere?) Also, I think the replacement somehow needs the new runtime stuff from li

Re: r307175 - [Sema] Don't allow -Wunguarded-availability to be silenced with redecls

Thanks for the fast reply! On Jul 6, 2017 11:42 PM, "Erik Pilkington" wrote: On 7/6/17 2:12 PM, Nico Weber wrote: We currently rely on this for chromium; that's how the warning used to work when I added it. What's the transition plan? Can we have a flag to incrementally transition to whatever

Re: [PATCH] D32914: Introduce Wzero-as-null-pointer-constant.

On Thu, Jul 13, 2017 at 1:38 PM, Roman Lebedev via Phabricator via cfe-commits wrote: > lebedev.ri added a comment. > > PR #33771 filled. > IMHO the problems with this diagnostic should be resolved before 5.0 > iirc gcc warns in that case too (?) Als

r308044 - Add documentation for @available

Author: nico Date: Fri Jul 14 11:40:52 2017 New Revision: 308044 URL: http://llvm.org/viewvc/llvm-project?rev=308044&view=rev Log: Add documentation for @available https://reviews.llvm.org/D35379 Modified: cfe/trunk/docs/LanguageExtensions.rst cfe/trunk/include/clang/Basic/AttrDocs.td M

r308046 - Fix link in docs.

Author: nico Date: Fri Jul 14 11:45:36 2017 New Revision: 308046 URL: http://llvm.org/viewvc/llvm-project?rev=308046&view=rev Log: Fix link in docs. Modified: cfe/trunk/include/clang/Basic/AttrDocs.td Modified: cfe/trunk/include/clang/Basic/AttrDocs.td URL: http://llvm.org/viewvc/llvm-proje

r308048 - Fix flag names in @available docs.

Author: nico Date: Fri Jul 14 11:52:30 2017 New Revision: 308048 URL: http://llvm.org/viewvc/llvm-project?rev=308048&view=rev Log: Fix flag names in @available docs. Modified: cfe/trunk/docs/LanguageExtensions.rst Modified: cfe/trunk/docs/LanguageExtensions.rst URL: http://llvm.org/viewvc/l

Re: r308099 - [cxx_status] Add approved Toronto WG21 motions.

On Jul 15, 2017 11:43 AM, "Richard Smith via cfe-commits" < cfe-commits@lists.llvm.org> wrote: Author: rsmith Date: Sat Jul 15 08:42:36 2017 New Revision: 308099 URL: http://llvm.org/viewvc/llvm-project?rev=308099&view=rev Log: [cxx_status] Add approved Toronto WG21 motions. Modified: cfe/tr

Re: r308044 - Add documentation for @available

Aaron, https://clang.llvm.org/docs/AttributeReference.html#availability still doesn't have the AttrDocs.td change I made in this change 2 days ago. Do I have to do anything to get it to update? On Fri, Jul 14, 2017 at 2:40 PM, Nico Weber via cfe-commits < cfe-commits@lists.llvm.or

Re: r308044 - Add documentation for @available

hen we updated? If so, I'm happy to > continue to receive it to help resolve problems, but in the interim, > do you happen to know more about what's going on? > Tanya, ping? > > Thanks! > > ~Aaron > > > > > On Fri, Jul 14, 2017 at 2:40 PM, Nic

[libcxx] r308827 - Fix grammar-o in comment.

Author: nico Date: Sat Jul 22 08:16:42 2017 New Revision: 308827 URL: http://llvm.org/viewvc/llvm-project?rev=308827&view=rev Log: Fix grammar-o in comment. Modified: libcxx/trunk/include/__config Modified: libcxx/trunk/include/__config URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/

r308848 - Remove Driver::UseStdLib.

Author: nico Date: Sun Jul 23 09:31:47 2017 New Revision: 308848 URL: http://llvm.org/viewvc/llvm-project?rev=308848&view=rev Log: Remove Driver::UseStdLib. All but one place are checking options::OPT_nostdlib instead of looking at this field, so convert that one other place to doing that as well

Re: [PATCH] D35780: Introduce -nostdlib++ flag to disable linking the C++ standard library.

On Sun, Jul 23, 2017 at 3:08 PM, Joerg Sonnenberger via Phabricator via cfe-commits wrote: > joerg added a comment. > > I don't really like this. That's cool, you don't need to use the flag. > The reason why -lm is added explicitly on many targets is because the C++ > STL typically depends on

Re: [PATCH] D35780: Introduce -nostdlib++ flag to disable linking the C++ standard library.

But if you have alternative ideas on how to address this use case (statically linking a custom libc++ without having to duplicate all the default libs, in particular built-in ones like libbuiltin-rt), I'm happy to hear them, or course :-) On Jul 23, 2017 3:17 PM, "Nico Weber" wrote: On Sun, Jul

Re: [PATCH] D35780: Introduce -nostdlib++ flag to disable linking the C++ standard library.

On Jul 23, 2017 4:51 PM, "Joerg Sonnenberger" wrote: On Sun, Jul 23, 2017 at 03:17:32PM -0400, Nico Weber via cfe-commits wrote: > On Sun, Jul 23, 2017 at 3:08 PM, Joerg Sonnenberger via Phabricator via > cfe-commits wrote: > > > joerg added a comment. > &g

r308897 - Work around an MSVC2017 update 3 codegen bug.

Author: nico Date: Mon Jul 24 09:54:11 2017 New Revision: 308897 URL: http://llvm.org/viewvc/llvm-project?rev=308897&view=rev Log: Work around an MSVC2017 update 3 codegen bug. C2017 update 3 produces a clang that crashes when compiling clang. Disabling optimizations for StmtProfiler::VisitCXXOpe

Re: r308897 - Work around an MSVC2017 update 3 codegen bug.

We probably want this in 5.0. On Mon, Jul 24, 2017 at 12:54 PM, Nico Weber via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: nico > Date: Mon Jul 24 09:54:11 2017 > New Revision: 308897 > > URL: http://llvm.org/viewvc/llvm-project?rev=308897&view=rev > Lo

r308997 - Introduce -nostdlib++ flag to disable linking the C++ standard library.

Author: nico Date: Tue Jul 25 11:02:57 2017 New Revision: 308997 URL: http://llvm.org/viewvc/llvm-project?rev=308997&view=rev Log: Introduce -nostdlib++ flag to disable linking the C++ standard library. Projects that want to statically link their own C++ standard library currently need to pass -n

Re: [PATCH] D33277: [Clang][x86][Inline Asm] - Enum support for MS syntax

The test also fails on many other bots on http://lab.llvm.org:8011/console , a short excerpt: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/9702/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Ax86-ms-inline-asm-enum_feature.cpp http://lab.llvm.org:8011/builders/clang-cmake-aarch64

Re: [PATCH] D35780: Introduce -nostdlib++ flag to disable linking the C++ standard library.

On Tue, Jul 25, 2017 at 2:53 PM, Joerg Sonnenberger wrote: > On Sun, Jul 23, 2017 at 07:06:25PM -0400, Nico Weber via cfe-commits wrote: > > If you need this behavior for something, that sounds like something a > > -nodefaultlibs++ could do. -nostdlib++ is really meant t

r322573 - Add va_start()/va_copy()/va_end to Builtins.def

Author: nico Date: Tue Jan 16 08:55:41 2018 New Revision: 322573 URL: http://llvm.org/viewvc/llvm-project?rev=322573&view=rev Log: Add va_start()/va_copy()/va_end to Builtins.def That way, clang suggests including stdarg.h when these are used in C files. https://reviews.llvm.org/D42085 Modified:

r322611 - Make DiagnosticsEngine() take DiagOpts as DiagnosticsEngine.

Author: nico Date: Tue Jan 16 18:55:27 2018 New Revision: 322611 URL: http://llvm.org/viewvc/llvm-project?rev=322611&view=rev Log: Make DiagnosticsEngine() take DiagOpts as DiagnosticsEngine. No behavior change, but makes it a bit clearer that DiagnosticsEngine adds a ref to DiagOpts. Modified:

r322652 - [clang-cl] Let /FA output use intel assembly.

Author: nico Date: Wed Jan 17 05:34:20 2018 New Revision: 322652 URL: http://llvm.org/viewvc/llvm-project?rev=322652&view=rev Log: [clang-cl] Let /FA output use intel assembly. cl's assembly output is in intel syntax, so clang-cl's should be too, PR35031. https://reviews.llvm.org/D42157 Modified

r322674 - Attempt to fix test/Driver/masm.c on the ARM bots.

Author: nico Date: Wed Jan 17 08:03:08 2018 New Revision: 322674 URL: http://llvm.org/viewvc/llvm-project?rev=322674&view=rev Log: Attempt to fix test/Driver/masm.c on the ARM bots. Modified: cfe/trunk/test/Driver/masm.c Modified: cfe/trunk/test/Driver/masm.c URL: http://llvm.org/viewvc/llv

Re: [PATCH] D42157: [clang-cl] Let /FA output use intel assembly.

r322674 attempts to fix. On Wed, Jan 17, 2018 at 10:54 AM, Yvan Roux via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hi Nico, > > On 17 January 2018 at 14:35, Nico Weber via Phabricator via > cfe-commits wrote: > > thakis closed this revision. > > thakis added a comment. > > > > r322652,

r322901 - Remove TautologicalInRangeCompare from Extra and TautologicalCompare.

Author: nico Date: Thu Jan 18 13:40:27 2018 New Revision: 322901 URL: http://llvm.org/viewvc/llvm-project?rev=322901&view=rev Log: Remove TautologicalInRangeCompare from Extra and TautologicalCompare. This removes the following (already default-off) warnings from -Wextra: -Wtautological-type-li

r323218 - clang-format: Support formatting Java 8 interface default methods.

Author: nico Date: Tue Jan 23 08:30:56 2018 New Revision: 323218 URL: http://llvm.org/viewvc/llvm-project?rev=323218&view=rev Log: clang-format: Support formatting Java 8 interface default methods. Modified: cfe/trunk/lib/Format/UnwrappedLineParser.cpp cfe/trunk/unittests/Format/FormatTes

r323226 - clang-format: Support macros in front of @interface / @protocol for ObjC code.

Author: nico Date: Tue Jan 23 09:10:25 2018 New Revision: 323226 URL: http://llvm.org/viewvc/llvm-project?rev=323226&view=rev Log: clang-format: Support macros in front of @interface / @protocol for ObjC code. Modified: cfe/trunk/lib/Format/UnwrappedLineParser.cpp cfe/trunk/lib/Format/Unw

r323228 - Name two bool parameters. No behavior change.

Author: nico Date: Tue Jan 23 09:29:41 2018 New Revision: 323228 URL: http://llvm.org/viewvc/llvm-project?rev=323228&view=rev Log: Name two bool parameters. No behavior change. Modified: cfe/trunk/lib/Format/FormatToken.h Modified: cfe/trunk/lib/Format/FormatToken.h URL: http://llvm.org/vie

r323293 - Fix typo in comment.

Author: nico Date: Tue Jan 23 17:45:57 2018 New Revision: 323293 URL: http://llvm.org/viewvc/llvm-project?rev=323293&view=rev Log: Fix typo in comment. Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp URL: http://llvm.org/viewvc/llvm-projec

Re: r323218 - clang-format: Support formatting Java 8 interface default methods.

348:5: note: here > case tok::kw_case: > ^~~~ > cc1plus: all warnings being treated as errors > ninja: build stopped: subcommand failed. > > Please have a look? > > Thanks > > Galina > > On Tue, Jan 23, 2018 at 8:30 AM, Nico Weber via cfe-commits < &

r323294 - Attempt to fix implicit-fallthrough warning after r323218.

Author: nico Date: Tue Jan 23 17:47:22 2018 New Revision: 323294 URL: http://llvm.org/viewvc/llvm-project?rev=323294&view=rev Log: Attempt to fix implicit-fallthrough warning after r323218. Modified: cfe/trunk/lib/Format/UnwrappedLineParser.cpp Modified: cfe/trunk/lib/Format/UnwrappedLinePar

Re: r323330 - clang-cl: Parse /permissive-, /Bt, Bt+ (PR32672)

(see also this thread for some prior discussion on /permissive-: https://marc.info/?t=14930460853&r=1&w=2 Ignoring seems like a good thing to do for now.) On Wed, Jan 24, 2018 at 10:18 AM, Hans Wennborg via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: hans > Date: Wed Jan 24 07:

r323426 - clang-cl: Simplify handling of /arch: flag.

Author: nico Date: Thu Jan 25 06:38:29 2018 New Revision: 323426 URL: http://llvm.org/viewvc/llvm-project?rev=323426&view=rev Log: clang-cl: Simplify handling of /arch: flag. r213083 initially implemented /arch: support by mapping it to CPU features. Then r241077 additionally mapped it to CPU, wh

r323433 - [clang-cl] Add support for /arch:AVX512F and /arch:AVX512

Author: nico Date: Thu Jan 25 07:24:43 2018 New Revision: 323433 URL: http://llvm.org/viewvc/llvm-project?rev=323433&view=rev Log: [clang-cl] Add support for /arch:AVX512F and /arch:AVX512 For /arch:AVX512F: clang-cl and cl.exe both defines __AVX512F__ __AVX512CD__. clang-cl also defines __AVX512

r323473 - Don't let test write to the source dir after r323426.

Author: nico Date: Thu Jan 25 13:49:03 2018 New Revision: 323473 URL: http://llvm.org/viewvc/llvm-project?rev=323473&view=rev Log: Don't let test write to the source dir after r323426. Modified: cfe/trunk/test/Driver/cl-x86-flags.c Modified: cfe/trunk/test/Driver/cl-x86-flags.c URL: http://

Re: [PATCH] D35338: Add the -fdestroy-globals flag

I'd love to use this flag in non-firmware code FWIW. On Fri, Jan 26, 2018 at 4:07 PM, Ian Tessier via Phabricator via cfe-commits wrote: > itessier added a comment. > > > That seems like a nice win and I like the convenience of this approach. > That said I've just remembered that there's a threa

Re: [PATCH] D34249: [libc++] Don't use UTIME_OMIT to detect utimensat on Apple

(To be clear, the patch as-is is 100% fine with me.) On Thu, Feb 1, 2018 at 11:44 AM, Duncan P. N. Exon Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Using runtime availability checking doesn't make sense for a system > Libc++, as you point out. If we add runtime checks they ought

r294772 - clang-format: don't break code using __has_include, PR31908

Author: nico Date: Fri Feb 10 13:36:52 2017 New Revision: 294772 URL: http://llvm.org/viewvc/llvm-project?rev=294772&view=rev Log: clang-format: don't break code using __has_include, PR31908 Modified: cfe/trunk/lib/Format/FormatToken.h cfe/trunk/lib/Format/TokenAnnotator.cpp cfe/trunk

Re: r293199 - Turn on -Wblock-capture-autoreleasing by default.

Hi Akira, this fires in internal chrome/ios code like so: somefile.m: error: block captures an autoreleasing out-parameter, which may result in use-after-free bugs [-Werror,-Wblock-capture-autoreleasing] if (error) { ^ somefile.m: note: declare the parameter __autoreleasin

Re: r293199 - Turn on -Wblock-capture-autoreleasing by default.

If I'm understanding you correctly, you're saying that clang implicitly marks the indirect NSError** parameter with __autoreleasing, so there's no bug here. Is that correct? If so, should Wblock-capture-autoreleasing just not fire on parameters that are already implicitly marked as __autoreleasing?

Re: [PATCH] D30312: Fix unix.Malloc analysis crasher when allocating dynamic arrays w/unbound statements (fix PR32050)

This looks pretty similar to https://reviews.llvm.org/D27849 – are you synced to trunk? On Thu, Feb 23, 2017 at 5:42 PM, Kevin Marshall via Phabricator via cfe-commits wrote: > kmarshall created this revision. > > The extent calculation function had a bug which caused it to ignore if the > size

r296160 - clang-format: Fix many Objective-C formatting regressions from r289428

Author: nico Date: Fri Feb 24 13:10:12 2017 New Revision: 296160 URL: http://llvm.org/viewvc/llvm-project?rev=296160&view=rev Log: clang-format: Fix many Objective-C formatting regressions from r289428 r289428 added a separate language kind for Objective-C, but kept many "Language == LK_Cpp" chec

r296161 - clang-format: Enable include sorting for style=Chromium

Author: nico Date: Fri Feb 24 13:13:59 2017 New Revision: 296161 URL: http://llvm.org/viewvc/llvm-project?rev=296161&view=rev Log: clang-format: Enable include sorting for style=Chromium Modified: cfe/trunk/lib/Format/Format.cpp Modified: cfe/trunk/lib/Format/Format.cpp URL: http://llvm.org

r296166 - clang-format: Don't leave behind temp files in -i mode on Windows, PR26125

Author: nico Date: Fri Feb 24 14:49:00 2017 New Revision: 296166 URL: http://llvm.org/viewvc/llvm-project?rev=296166&view=rev Log: clang-format: Don't leave behind temp files in -i mode on Windows, PR26125 Fix and analysis by Wei Mao (see bug), test by me. Added: cfe/trunk/test/Format/inpla

r296171 - Try to unbreak tests after r296166

Author: nico Date: Fri Feb 24 15:01:43 2017 New Revision: 296171 URL: http://llvm.org/viewvc/llvm-project?rev=296171&view=rev Log: Try to unbreak tests after r296166 Looks like %T isn't per-test but per-test-directory, and the rm was deleting temp files written by other tests in test/Format. Lim

RE: r296171 - Try to unbreak tests after r296166

m: cannot remove `C:\\Buildbot\\Slave\\llvm-clang-lld-x86_64-scei-ps4- > windows10pro-fast\\llvm.obj\\tools\\clang\\test\\Format\\Output/inplace*': > Invalid argument > > Can you fix the test? > > Douglas Yung > > > -Original Message- > > From: cfe-commits [mail

Re: r296166 - clang-format: Don't leave behind temp files in -i mode on Windows, PR26125

Thanks, I had fixed this in 171 a bit over an hour before your mail. On Feb 24, 2017 5:17 PM, "Renato Golin via cfe-commits" < cfe-commits@lists.llvm.org> wrote: > On 24 February 2017 at 20:49, Nico Weber via cfe-commits > wrote: > > Author: nico > > Date

Re: [PATCH] D30385: clang-format: Don't leave behind temp files in -i mode on Windows, PR26125, reloaded

FILE_SHARE_DELETE is for being able to request a file to be deleted when it's closed, which is too late, right? I didn't write the code in Path.inc, but from what I understand you can't generally overwrite a file that's still open on Windows, and Path.inc tries to work around this -- but the worka

Re: [PATCH] D30385: clang-format: Don't leave behind temp files in -i mode on Windows, PR26125, reloaded

Is that a "this patch is good" or a "please rewrite"? On Mon, Feb 27, 2017 at 1:50 PM, Reid Kleckner via Phabricator < revi...@reviews.llvm.org> wrote: > rnk added a comment. > > My understanding is that Windows doesn't allow you to delete a file that > has been opened and mapped into any process

r296387 - UBSan docs: Explicitly mention that `-fsanitize=unsigned-integer-overflow` does not catch UB.

Author: nico Date: Mon Feb 27 15:27:07 2017 New Revision: 296387 URL: http://llvm.org/viewvc/llvm-project?rev=296387&view=rev Log: UBSan docs: Explicitly mention that `-fsanitize=unsigned-integer-overflow` does not catch UB. https://reviews.llvm.org/D27455 Modified: cfe/trunk/docs/Undefined

r296408 - clang-format: Don't leave behind temp files in -i mode on Windows, PR26125, reloaded

Author: nico Date: Mon Feb 27 16:59:58 2017 New Revision: 296408 URL: http://llvm.org/viewvc/llvm-project?rev=296408&view=rev Log: clang-format: Don't leave behind temp files in -i mode on Windows, PR26125, reloaded Second attempt after http://llvm.org/viewvc/llvm-project?rev=296166&view=rev In

Re: r296171 - Try to unbreak tests after r296166

gt;> ng-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\tools\\ >> clang\\test\\Format\\Output/inplace*': Invalid argument >> >> Can you fix the test? >> >> Douglas Yung >> >> > -Original Message- >> > From: cfe-commits [mailto:cfe-commits

Re: r296460 - clang/test/Format/inplace.cpp: Avoid using wildcard.

Thanks! That's a good technique, I'll remember it for next time. I wonder if %T should work like that... On Feb 28, 2017 5:17 AM, "NAKAMURA Takumi via cfe-commits" < cfe-commits@lists.llvm.org> wrote: > Author: chapuni > Date: Tue Feb 28 04:05:56 2017 > New Revision: 296460 > > URL: http://llvm.o

Re: r296453 - [clang-format] Fix test failure caused by "rm" on some buildbots.

It's needed: when clang-format does leave temp files behind, they will accumulate over builds and even if that's then fixed, the test would still fail because of the temp files from prior builds. Thankfully, takuni fixed this better in r296460. On Feb 28, 2017 4:14 AM, "Haojian Wu via cfe-commits"

r296749 - Don't write to LLVMStyle.JavaScriptQuotes twice. No behavior change.

Author: nico Date: Thu Mar 2 08:51:54 2017 New Revision: 296749 URL: http://llvm.org/viewvc/llvm-project?rev=296749&view=rev Log: Don't write to LLVMStyle.JavaScriptQuotes twice. No behavior change. Modified: cfe/trunk/lib/Format/Format.cpp Modified: cfe/trunk/lib/Format/Format.cpp URL: ht

Re: [libcxx] r296919 - Fix hash requirements check in __hash_table.

"the specified hash does not meet the Hash requirements" isn't a very actionable diagnostic. Is it possible to use some warning text that lets people know what they need to do to make the compiler happy, instead of just telling them that the compiler is unhappy? On Fri, Mar 3, 2017 at 5:35 PM, Eri

Re: [PATCH] D30773: Make git-clang-format python 3 compatible

Consider landing the obvious bits (print function, mostly) separately and use this only for the interesting bits. On Thu, Mar 9, 2017 at 11:10 AM, Michał Górny via Phabricator via cfe-commits wrote: > mgorny added inline comments. > > > > Comment at: tools/clang-format/git-clang

Re: [cfe-dev] Disable fms-extensions?

In addition to that: If I remember correctly, -fms-extensions is only enabled if your triple's OS is win32 and your triple's environment is MSVC. It's not enabled when targeting MinGW for example. The reason it's enabled with an foo-windows-msvc triple is that it's required to parse the system's he

Re: [PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type

I'm a bit surprised that this landed, given that gcc bug. I can see the motivation for the gcc bug: If you say your enum is going to need underlying 8 bits, then warning that your bitfield where you store it is smaller _is_ surprising. I'm not sure if landing this while gcc still behaves the way i

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

(In addition to rnk's question: We build with -Werror, but Wliblto seems unaffected by this. Because of that, our bots didn't catch the new warning and we only noticed this when a human did a local build after we updated compilers and saw a wall of warnings. It'd be good if Wliblto was affected by

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits < cfe-commits@lists.llvm.org> wrote: > mehdi_amini added a comment. > > In https://reviews.llvm.org/D25932#601842, @rnk wrote: > > > In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote: > > > > > We ship `clang + libLTO + ld64`

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini wrote: > > On Nov 21, 2016, at 2:27 PM, Nico Weber wrote: > > On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits lists.llvm.org> wrote: > >> mehdi_amini added a comment. >> >> In https://reviews.llvm.org/D25932#601842, @rnk wrote: >> >> > I

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

In what way is this chromium specific? It's "all non-xcode uses of clang on mac", no? On Nov 21, 2016 7:29 PM, "Mehdi Amini" wrote: > > On Nov 21, 2016, at 2:44 PM, Nico Weber wrote: > > On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini > wrote: > >> >> On Nov 21, 2016, at 2:27 PM, Nico Weber wrot

Re: [PATCH] D26944: Suppress -Wliblto warning when -flto is not present

Lgtm, works for me. Seems like a good compromise. On Nov 21, 2016 6:29 PM, "Reid Kleckner" wrote: > rnk created this revision. > rnk added reviewers: mehdi_amini, thakis. > rnk added a subscriber: cfe-commits. > > Without -flto, it's unlikely that users will experience LLVM version > skew. The s

Re: r287229 - Link include-fixer into libclang if clang-tools-extra is checked out.

I just did a fresh build with `cmake -GNinja ../llvm-rw/ -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON`. `ninja check-clang` failed with: FAILED: lib/libclang.so.4.0 : && /usr/bin/c++ -fPIC -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-

Re: r287229 - Link include-fixer into libclang if clang-tools-extra is checked out.

Sorry for the noise, I just forgot to update my clang/tools/extra :-/ On Tue, Nov 22, 2016 at 1:50 PM, Nico Weber wrote: > I just did a fresh build with `cmake -GNinja ../llvm-rw/ > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON`. `ninja > check-clang` failed with: > > FAILED: lib/libcla

[PATCH] D26984: Unconditionally pass -lto_library, remove -Wliblto warning.

thakis created this revision. thakis added reviewers: rnk, mehdi_amini. thakis added a subscriber: cfe-commits. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on disk, even if -flto is not being used. The motivation for that change was that if a de

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

After some discussion on IRC, we agreed to give https://reviews.llvm.org/D26984 a try. On Tue, Nov 22, 2016 at 11:41 AM, Mehdi Amini wrote: > This has been like that forever, this is not new with 3.9. > Note also that the system ar/ranlib are sensitive to the environment > DYLD_LIBRARY_PATH and

[PATCH] D26984: Unconditionally pass -lto_library, remove -Wliblto warning.

thakis closed this revision. thakis added a comment. 287685, thanks! https://reviews.llvm.org/D26984 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r287685 - darwin: Unconditionally pass -lto_library, remove -Wliblto warning.

Author: nico Date: Tue Nov 22 13:38:07 2016 New Revision: 287685 URL: http://llvm.org/viewvc/llvm-project?rev=287685&view=rev Log: darwin: Unconditionally pass -lto_library, remove -Wliblto warning. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on

Re: r287774 - Remove C++ default arg side table for MS ABI ctor closures

Cool, thanks! Should we also have a test for using a default arg with a pch? Now that ASTContext doesn't have this table any more, it'll work, but maybe it's good to have a regression test for the issue in the PR? On Wed, Nov 23, 2016 at 11:51 AM, Reid Kleckner via cfe-commits < cfe-commits@lists.

Re: Embedded Bitcode in Object Files

It looks like patches 1 and 2 made it but 3 and 4 didn't. Do you no longer need them? On Mon, Feb 29, 2016 at 2:08 PM, Steven Wu via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Ping. I don't know who is the best review for the patches. Thanks for > Rafael looking at the LLVM change. Richa

Re: [RFC] Embedded bitcode and related upstream (Part II)

Hi Steven, On Fri, Jun 3, 2016 at 2:36 PM, Steven Wu via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hi everyone > > I am still in the process of upstreaming some improvements to the embed > bitcode option. If you want more background, you can read the previous RFC ( > http://lists.llvm.or

Re: [PATCH] D27545: Don't assert when redefining a built-in macro in a PCH, PR29119

(I replied to comments about 1h ago, looks like phab is not in the mood for sending a mail for that for some reason. I did use the "Leap into action" submit button.) On Wed, Dec 7, 2016 at 9:19 PM, Richard Smith via Phabricator < revi...@reviews.llvm.org> wrote: > rsmith added inline comments. >

<    5   6   7   8   9   10   11   12   13   14   >