r286525 - [Sema] Fix-up for MSVC, which is stricter about template types.

Author: jrose Date: Thu Nov 10 17:41:18 2016 New Revision: 286525 URL: http://llvm.org/viewvc/llvm-project?rev=286525&view=rev Log: [Sema] Fix-up for MSVC, which is stricter about template types. Modified: cfe/trunk/lib/Sema/SemaType.cpp Modified: cfe/trunk/lib/Sema/SemaType.cpp URL: http:/

[PATCH] D26530: Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.

chandlerc created this revision. chandlerc added a reviewer: rsmith. chandlerc added a subscriber: cfe-commits. Herald added a subscriber: mcrosier. The latter agrees with most existing diagnostics and the C and C++ standards. https://reviews.llvm.org/D26530 Files: include/clang/Basic/Diagnos

[PATCH] D26530: Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.

chandlerc updated this revision to Diff 77574. chandlerc added a comment. Update the tests accordingly. https://reviews.llvm.org/D26530 Files: include/clang/Basic/DiagnosticParseKinds.td include/clang/Basic/DiagnosticSemaKinds.td test/Parser/objc-property-syntax.m test/Sema/constant-con

r286531 - Don't require nullability on 'va_list' harder.

Author: jrose Date: Thu Nov 10 18:23:59 2016 New Revision: 286531 URL: http://llvm.org/viewvc/llvm-project?rev=286531&view=rev Log: Don't require nullability on 'va_list' harder. Platform headers don't always define 'va_list' in terms of Clang's '__builtin_va_list', so in addition to checking for

[PATCH] D25850: Accept nullability annotations (_Nullable) on array parameters

jordan_rose closed this revision. jordan_rose added a comment. Committed as https://reviews.llvm.org/rL286519. Repository: rL LLVM https://reviews.llvm.org/D25850 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-b

[PATCH] D26108: Add -Wnullability-completeness-on-arrays.

jordan_rose closed this revision. jordan_rose added a comment. Committed as https://reviews.llvm.org/rL286520, with a slight fix-up for MSVC in https://reviews.llvm.org/rL286525. Repository: rL LLVM https://reviews.llvm.org/D26108 ___ cfe-commit

[PATCH] D26109: Warn when 'assume_nonnull' infers nullability within an array.

jordan_rose closed this revision. jordan_rose added a comment. Committed as https://reviews.llvm.org/rL286521. Repository: rL LLVM https://reviews.llvm.org/D26109 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-b

[PATCH] D26227: Don't require nullability on 'va_list'.

jordan_rose closed this revision. jordan_rose added a comment. Committed in https://reviews.llvm.org/rL286522, with a fix-up to make the check for va_lists more conservative in https://reviews.llvm.org/rL286531. Repository: rL LLVM https://reviews.llvm.org/D26227 _

r286533 - Speculative fix for va_list/nullability test on Hexagon and PPC.

Author: jrose Date: Thu Nov 10 18:55:14 2016 New Revision: 286533 URL: http://llvm.org/viewvc/llvm-project?rev=286533&view=rev Log: Speculative fix for va_list/nullability test on Hexagon and PPC. PowerPC's va_list, at least, is a typedef for an array, which means it decays to a pointer in parame

r286534 - PR30937: don't devirtualize if we find that the callee is a pure virtual

Author: rsmith Date: Thu Nov 10 19:01:31 2016 New Revision: 286534 URL: http://llvm.org/viewvc/llvm-project?rev=286534&view=rev Log: PR30937: don't devirtualize if we find that the callee is a pure virtual function. In that case, there is no requirement that the callee is actually defined, and the

r286542 - Don't require nullability on 'va_list', even when it's a pointer.

Author: jrose Date: Thu Nov 10 19:29:18 2016 New Revision: 286542 URL: http://llvm.org/viewvc/llvm-project?rev=286542&view=rev Log: Don't require nullability on 'va_list', even when it's a pointer. Take 3! This should finally fix the Hexagon, PPC, and Windows bots. rdar://problem/25846421 Modif

r286541 - Revert "Speculative fix for va_list/nullability test on Hexagon and PPC."

Author: jrose Date: Thu Nov 10 19:29:15 2016 New Revision: 286541 URL: http://llvm.org/viewvc/llvm-project?rev=286541&view=rev Log: Revert "Speculative fix for va_list/nullability test on Hexagon and PPC." This reverts commit r286533. At this point an array really is still an array, but the probl

r286543 - Define __ANDROID_API__ when specified as part of an Android target.

Author: srhines Date: Thu Nov 10 19:29:39 2016 New Revision: 286543 URL: http://llvm.org/viewvc/llvm-project?rev=286543&view=rev Log: Define __ANDROID_API__ when specified as part of an Android target. Summary: This macro should be defined only when the user directly specifies an API level as par

[PATCH] D26491: Define __ANDROID_API__ when specified as part of an Android target.

This revision was automatically updated to reflect the committed changes. Closed by commit rL286543: Define __ANDROID_API__ when specified as part of an Android target. (authored by srhines). Changed prior to commit: https://reviews.llvm.org/D26491?vs=77446&id=77578#toc Repository: rL LLVM

[PATCH] D26227: Don't require nullability on 'va_list'.

jordan_rose added a comment. One more fix-up in https://reviews.llvm.org/rL286542. Hopefully the last one. Repository: rL LLVM https://reviews.llvm.org/D26227 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/m

[PATCH] D26534: [PPC] add altivec.h functions for converting a vector of half precision to a vector of single precision

sfertile created this revision. sfertile added reviewers: nemanjai, amehsan, kbarton, syzaara, jtony, lei. sfertile added subscribers: cfe-commits, echristo. sfertile set the repository for this revision to rL LLVM. Change adds 2 functions to altivec.h vector float vec_extract_fp32_from_shorth (v

Re: r286534 - PR30937: don't devirtualize if we find that the callee is a pure virtual

Could we emit llvm.unreachable in this case? — Mehdi > On Nov 10, 2016, at 5:01 PM, Richard Smith via cfe-commits > wrote: > > Author: rsmith > Date: Thu Nov 10 19:01:31 2016 > New Revision: 286534 > > URL: http://llvm.org/viewvc/llvm-project?rev=286534&view=rev > Log: > PR30937: don't devir

Re: r286534 - PR30937: don't devirtualize if we find that the callee is a pure virtual

Thinking again, the method “can” be implemented I think. Forget it… — Mehdi > On Nov 10, 2016, at 6:11 PM, Mehdi Amini wrote: > > Could we emit llvm.unreachable in this case? > > — > Mehdi > >> On Nov 10, 2016, at 5:01 PM, Richard Smith via cfe-commits >> wrote: >> >> Author: rsmith >> D

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

sashab added a comment. Sorry, had this discussion elsewhere (https://bugs.chromium.org/p/chromium/issues/detail?id=648462). I'm uncertain at this point. There is currently a bug in GCC that means enums with an explicit underlying type (or enum classes, although the latter is to be fixed) are

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

mehdi_amini added a comment. > So when this modification tells the developer to add 'unsigned' to their > enum, they are subsequently causing a warning to occur in GCC. > > I have commented on the bug on GCC for this > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242#c28), but it looks > un

[PATCH] D26540: [Sema] Accept and ignore the leaf attribute

phosek created this revision. phosek added a subscriber: cfe-commits. phosek set the repository for this revision to rL LLVM. This is a GCC extension, Clang should accept the attribute without a warning for compatibility with GCC. https://llvm.org/bugs/show_bug.cgi?id=30980 Repository: rL LL

Re: r286534 - PR30937: don't devirtualize if we find that the callee is a pure virtual

On Thu, Nov 10, 2016 at 6:12 PM, Mehdi Amini via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Thinking again, the method “can” be implemented I think. Forget it… > It can be, but the context is a virtual dispatch, so an overrider won't actually be used, and you do get undefined behavior. E

[PATCH] D24933: Enable configuration files in clang

sepavloff added a comment. >> Config file set by environment variable is similar to default config file as >> user does not specify anything in command line. But the user must explicitly >> specify the file, it is not made automatically. > > Sorry, I don't understand this part. If a user speci

[PATCH] D25857: [tsan][clang] Introduce a function attribute to disable TSan checking at run time

dvyukov accepted this revision. dvyukov added a comment. This revision is now accepted and ready to land. > Alternatively, I could drop this aspect of the test altogether since I have > an assert in the llvm pass. Dropping the check is fine in this case. https://reviews.llvm.org/D25857

Re: [PATCH] D25816: Use descriptive message if list initializer is incorrectly parenthesized.

Is it OK to commit this patch? Thanks, --Serge 2016-10-21 18:21 GMT+07:00 Alex Lorenz : > arphaman added a subscriber: rsmith. > arphaman added a comment. > > LGTM, I added Richard in case he has something to add. > > > I chose to retain current clang behavior and reject questionable code. > GCC

r286567 - Mirror the llvm changes that split Bitcode/ReaderWriter.h

Author: tejohnson Date: Thu Nov 10 23:35:12 2016 New Revision: 286567 URL: http://llvm.org/viewvc/llvm-project?rev=286567&view=rev Log: Mirror the llvm changes that split Bitcode/ReaderWriter.h The change in D26502 splits ReaderWriter.h, which contains the APIs into both the BitReader and BitWrit

[PATCH] D26410: [CodeGen] Don't emit the same global block multiple times.

rjmccall added a comment. This looks great. One minor tweak and then it's ready. Comment at: lib/CodeGen/CGBlocks.cpp:1057 +void CodeGenModule::putAddrOfGlobalBlock(const BlockExpr *BE, + llvm::Constant *Addr) { + bool Ok = EmittedGloba

[PATCH] D26511: [clang-tidy] Rename modernize-use-default to modernize-use-equals-default

Prazek added a comment. I think this change is not required at first place. It is introduced because of "modernize-use-delete" was too ambiguous because of operator delete, so it was changed to "modernize-use-equals-delete". But this case is not ambiguous at all, so I don't see point changing th

[PATCH] D21298: [Clang-tidy] delete null check

Prazek added inline comments. Comment at: test/clang-tidy/misc-delete-null-pointer.cpp:11 + } + // CHECK-FIXES: delete p; + int *p3 = new int[3]; Is there check-fixes-not? This seems to be required here, because even if the fixit won't happen here, the test w

[PATCH] D26511: [clang-tidy] Rename modernize-use-default to modernize-use-equals-default

malcolm.parsons added a comment. In https://reviews.llvm.org/D26511#592665, @Prazek wrote: > It is introduced because of "modernize-use-delete" was too ambiguous because > of operator delete, so it was changed to "modernize-use-equals-delete". But > this case is not ambiguous at all, so I don't

<    1   2