[PATCH] D32478: [clang-format] Fix AlignOperands when BreakBeforeBinaryOperators is set

djasper added a comment. When you say "this doesn't happen in tests", do you mean this never happens when there are parentheses around the expression? Comment at: unittests/Format/FormatTest.cpp:2476 "bool value = a\n" -

[PATCH] D33282: clang-format: fix prefix for doxygen comments after member

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Looks good. Thank you! https://reviews.llvm.org/D33282 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/

[PATCH] D33282: clang-format: fix prefix for doxygen comments after member

Typz added a comment. I don't have commit access, can someone please commit this patch? https://reviews.llvm.org/D33282 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33285: clang-format: do not reflow bullet lists

krasimir added inline comments. Comment at: lib/Format/BreakableToken.cpp:313 + // Numbered lists may also start with a number followed by '.' + static const char *kNumberedListPattern = "^[0-9]+\\. "; + hasSpecialMeaningPrefix = hasSpecialMeaningPrefix || A p

[PATCH] D33282: clang-format: fix prefix for doxygen comments after member

krasimir added a comment. I'll commit this. https://reviews.llvm.org/D33282 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r303330 - clang-format: fix prefix for doxygen comments after member

Author: krasimir Date: Thu May 18 02:36:21 2017 New Revision: 303330 URL: http://llvm.org/viewvc/llvm-project?rev=303330&view=rev Log: clang-format: fix prefix for doxygen comments after member Summary: Doxygen supports putting documentation blocks after member, by adding an additional < marker i

[PATCH] D33282: clang-format: fix prefix for doxygen comments after member

This revision was automatically updated to reflect the committed changes. Closed by commit rL303330: clang-format: fix prefix for doxygen comments after member (authored by krasimir). Changed prior to commit: https://reviews.llvm.org/D33282?vs=99307&id=99402#toc Repository: rL LLVM https://

[PATCH] D33238: [clang-format] Make NoLineBreakFormatter respect MustBreakBefore

krasimir updated this revision to Diff 99405. krasimir added a comment. - Add comment about import statements. https://reviews.llvm.org/D33238 Files: lib/Format/TokenAnnotator.cpp lib/Format/UnwrappedLineFormatter.cpp Index: lib/Format/UnwrappedLineFormatter.cpp ==

[PATCH] D33238: [clang-format] Make NoLineBreakFormatter respect MustBreakBefore

This revision was automatically updated to reflect the committed changes. Closed by commit rL303332: [clang-format] Make NoLineBreakFormatter respect MustBreakBefore (authored by krasimir). Changed prior to commit: https://reviews.llvm.org/D33238?vs=99405&id=99407#toc Repository: rL LLVM ht

r303332 - [clang-format] Make NoLineBreakFormatter respect MustBreakBefore

Author: krasimir Date: Thu May 18 03:07:52 2017 New Revision: 303332 URL: http://llvm.org/viewvc/llvm-project?rev=303332&view=rev Log: [clang-format] Make NoLineBreakFormatter respect MustBreakBefore Summary: This patch makes NoLineBreakFormatter to insert a break before tokens where MustBreakBef

[PATCH] D32477: [clang-format] Allow customizing the penalty for breaking assignment

Typz updated this revision to Diff 99415. Typz added a comment. Add test to verify the option actually has some effect https://reviews.llvm.org/D32477 Files: include/clang/Format/Format.h lib/Format/Format.cpp lib/Format/TokenAnnotator.cpp unittests/Format/FormatTest.cpp Index: unitte

r303343 - [index] Record references to class receivers used in property references

Author: arphaman Date: Thu May 18 05:43:11 2017 New Revision: 303343 URL: http://llvm.org/viewvc/llvm-project?rev=303343&view=rev Log: [index] Record references to class receivers used in property references rdar://32250025 Modified: cfe/trunk/lib/Index/IndexBody.cpp cfe/trunk/test/Index

[clang-tools-extra] r303344 - Fix 'not all control paths return a value' warning on windows buildbots.

Author: rksimon Date: Thu May 18 05:48:23 2017 New Revision: 303344 URL: http://llvm.org/viewvc/llvm-project?rev=303344&view=rev Log: Fix 'not all control paths return a value' warning on windows buildbots. Modified: clang-tools-extra/trunk/clang-tidy/ClangTidyDiagnosticConsumer.cpp Modified

[PATCH] D33314: clang-format: Add option to remove semicolon at end of namespace

Typz created this revision. Herald added a subscriber: klimek. This option allows cleaning up namespace declaration, by removing the extra semicolon after namespace closing brace. https://reviews.llvm.org/D33314 Files: include/clang/Format/Format.h lib/Format/Format.cpp lib/Format/Namespa

[PATCH] D32480: [clang-format] Add BinPackNamespaces option

Typz updated this revision to Diff 99421. Typz added a comment. clang-format: Add CompactNamespaces option - Change option name to CompactNamespaces - Clarify & test behavior when wrapping is needed - Separate from the 'remove semicolon' patch https://reviews.llvm.org/D32480 Files: include/c

[PATCH] D33314: clang-format: Add option to remove semicolon at end of namespace

krasimir added a comment. I think that this is more of a linter check and as such doesn't really belong to clang-format. @djasper: what do you think about this? https://reviews.llvm.org/D33314 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D32480: clang-format: Add CompactNamespaces option

Typz marked 2 inline comments as done. Typz added inline comments. Comment at: include/clang/Format/Format.h:153 + /// \endcode + bool AllowSemicolonAfterNamespace; + Typz wrote: > djasper wrote: > > While I am not entirely opposed to this feature, I think it s

Re: [clang-tools-extra] r303344 - Fix 'not all control paths return a value' warning on windows buildbots.

Thanks! On Thu, May 18, 2017 at 12:48 PM, Simon Pilgrim via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: rksimon > Date: Thu May 18 05:48:23 2017 > New Revision: 303344 > > URL: http://llvm.org/viewvc/llvm-project?rev=303344&view=rev > Log: > Fix 'not all control paths return a valu

[PATCH] D33314: clang-format: Add option to remove semicolon at end of namespace

Typz added a comment. Is this not the same reasoning as the whole NamespaceEndCommentsFixer? https://reviews.llvm.org/D33314 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

kparzysz added a comment. If you have no further comments, could you accept this review? Repository: rL LLVM https://reviews.llvm.org/D33284 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cf

[PATCH] D33285: clang-format: do not reflow bullet lists

Typz marked an inline comment as done. Typz added inline comments. Comment at: lib/Format/BreakableToken.cpp:313 + // Numbered lists may also start with a number followed by '.' + static const char *kNumberedListPattern = "^[0-9]+\\. "; + hasSpecialMeaningPrefix = hasSpecialMe

[PATCH] D33285: clang-format: do not reflow bullet lists

Typz updated this revision to Diff 99427. Typz added a comment. - Use static regex to avoid recreating it each time - Add more tests https://reviews.llvm.org/D33285 Files: lib/Format/BreakableToken.cpp unittests/Format/FormatTestComments.cpp Index: unittests/Format/FormatTestComments.cpp =

[PATCH] D33053: [PowerPC] Implement vec_xxpermdi builtin.

nemanjai added a comment. Other than the few minor comments, this LGTM. Comment at: lib/CodeGen/CGBuiltin.cpp:8458 +if (getTarget().isLittleEndian()) { + ElemIdx0 = (~Index & 1) + 2; + ElemIdx1 = (~Index & 2) >> 1; Minor nit: please add a comment

[PATCH] D33285: clang-format: do not reflow bullet lists

krasimir added inline comments. Comment at: lib/Format/BreakableToken.cpp:313 + // Numbered lists may also start with a number followed by '.' + static const char *kNumberedListPattern = "^[0-9]+\\. "; + hasSpecialMeaningPrefix = hasSpecialMeaningPrefix || Typ

[PATCH] D32525: [clang-format] Add SpaceBeforeColon option

Typz added a comment. I checked the code of POCO, and it indeed follows this convention (though there does not seem to be any C++11 for loop indeed). We also use this style at our company. > Also see my comment. I could not find your comment... can you please re-post? > It's very hard to even

Re: r303224 - [modules] When creating a declaration, cache its owning module immediately

Hi, this is breaking our STL module builds. Can we revert this? We also have a minimal reproducer for our crash here http://teemperor.de/pub/stl_merging_issue.zip - Raphael 2017-05-17 2:24 GMT+02:00 Richard Smith via cfe-commits : > Author: rsmith > Date: Tue May 16 19:24:14 2017 > New Revision

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

Could you give some context on how r302938 is related to this? Thanks, Dehao On Wed, May 17, 2017 at 11:14 PM, Vitaly Buka wrote: > +Dehao Chen > it started from r302938 > > On Wed, May 17, 2017 at 8:09 PM Jordan Rose via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Thanks, this is

[PATCH] D32524: [clang-format] Fix MatchingOpeningBlockLineIndex computation

krasimir added a comment. Do you need me to commit this? https://reviews.llvm.org/D32524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32524: [clang-format] Fix MatchingOpeningBlockLineIndex computation

Typz added a comment. Indeed, I don't have commit access. But I was wondering if I should not get it, to simplify landing the patches after review. I read http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access about this, but I am still wondering what is considered a "track record of

[PATCH] D33285: clang-format: do not reflow bullet lists

Typz marked 3 inline comments as done. Typz added inline comments. Comment at: lib/Format/BreakableToken.cpp:313 + // Numbered lists may also start with a number followed by '.' + static const char *kNumberedListPattern = "^[0-9]+\\. "; + hasSpecialMeaningPrefix = hasSpecialMe

[PATCH] D33285: clang-format: do not reflow bullet lists

Typz updated this revision to Diff 99436. Typz marked an inline comment as done. Typz added a comment. Limit to 2 digits and not break before a matching numbered list sequence followed by a fullstop, to avoid interpreting numbers at the end of sentence as numbered bullets (and thus preventing re

[PATCH] D32524: [clang-format] Fix MatchingOpeningBlockLineIndex computation

krasimir added a comment. It should be enough for commit access. Mention your patches while requesting commit access. I'll submit this in the meantime. https://reviews.llvm.org/D32524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://l

r303353 - [clang-format] Fix MatchingOpeningBlockLineIndex computation

Author: krasimir Date: Thu May 18 10:16:24 2017 New Revision: 303353 URL: http://llvm.org/viewvc/llvm-project?rev=303353&view=rev Log: [clang-format] Fix MatchingOpeningBlockLineIndex computation Summary: Computed line index must be relative to the current 'parent' node, and thus use CurrentLines

[PATCH] D32524: [clang-format] Fix MatchingOpeningBlockLineIndex computation

This revision was automatically updated to reflect the committed changes. Closed by commit rL303353: [clang-format] Fix MatchingOpeningBlockLineIndex computation (authored by krasimir). Changed prior to commit: https://reviews.llvm.org/D32524?vs=99136&id=99442#toc Repository: rL LLVM https:

[PATCH] D33305: [ubsan] Add a check for pointer overflow UB

filcab added inline comments. Comment at: lib/CodeGen/CGExprScalar.cpp:3854 + const Twine &Name) { + Value *GEPVal = Builder.CreateInBoundsGEP(Ptr, IdxList, Name); + You're creating the GEP first (possibly triggering

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Yes, of course. Although "looks good to me" is acceptance whether or not I actually push a button in Phabricator. :) Repository: rL LLVM https://reviews.llvm.org/D33284 ___

[PATCH] D33191: [analyzer] ObjCGenerics: account for __kindof specifiers met along a chain of casts.

NoQ updated this revision to Diff 99443. NoQ added a comment. I think i found a relatively clean way of storing the kindof specifiers, which is within the most-specialized type object itself. Like, if we see `Foo` being casted to `Foo<__kindof X, Y>` and in another place to `Foo`, then we'd sto

[PATCH] D33191: [analyzer] ObjCGenerics: account for __kindof specifiers met along a chain of casts.

NoQ updated this revision to Diff 99444. NoQ added a comment. Added a bit more info in the code comments. https://reviews.llvm.org/D33191 Files: lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp test/Analysis/generics.m Index: test/Analysis/generics.m =

[PATCH] D33170: [X86] Adding avx512_vpopcntdq feature set and its intrinsics

craig.topper added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:7526 +llvm::Type *ResultType = ConvertType(E->getType()); +Value *X = EmitScalarExpr(E->getArg(0)); +llvm::Function *F = CGM.getIntrinsic(Intrinsic::ctpop, ResultType); oren_ben

[PATCH] D33191: [analyzer] ObjCGenerics: account for __kindof specifiers met along a chain of casts.

xazax.hun added a comment. In https://reviews.llvm.org/D33191#758583, @NoQ wrote: > I think i found a relatively clean way of storing the kindof specifiers, > which is within the most-specialized type object itself. > > Like, if we see `Foo` being casted to `Foo<__kindof X, Y>` and in > another

[PATCH] D33305: [ubsan] Add a check for pointer overflow UB

vsk added a comment. Thanks for the comments, responses inline -- Comment at: lib/CodeGen/CGExprScalar.cpp:3854 + const Twine &Name) { + Value *GEPVal = Builder.CreateInBoundsGEP(Ptr, IdxList, Name); + filcab wrote

[PATCH] D33272: Method loadFromCommandLine should be able to report errors

joerg added a comment. Can this use ErrorOr? https://reviews.llvm.org/D33272 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33304: [clang-tidy] Add a new module Android and a new check for file descriptors.

joerg added a comment. I find the use of "must" at the very least inappropriate. If there was no use case for not including it, it wouldn't be an option. There is also nothing really Android-specific here beside maybe the open64 mess. Repository: rL LLVM https://reviews.llvm.org/D33304 _

[PATCH] D33304: [clang-tidy] Add a new module Android and a new check for file descriptors.

yawanng updated this revision to Diff 99447. https://reviews.llvm.org/D33304 Files: clang-tidy/CMakeLists.txt clang-tidy/android/AndroidTidyModule.cpp clang-tidy/android/CMakeLists.txt clang-tidy/android/FileDescriptorCheck.cpp clang-tidy/android/FileDescriptorCheck.h clang-tidy/plugi

[PATCH] D33304: [clang-tidy] Add a new module Android and a new check for file descriptors.

srhines added a comment. In https://reviews.llvm.org/D33304#758621, @joerg wrote: > I find the use of "must" at the very least inappropriate. If there was no use > case for not including it, it wouldn't be an option. There is also nothing > really Android-specific here beside maybe the open64 m

[PATCH] D33191: [analyzer] ObjCGenerics: account for __kindof specifiers met along a chain of casts.

NoQ planned changes to this revision. NoQ added a comment. Todo: - See if the extra __kindofs leak into diagnostic messages. - Test how this behaves in cases (2) and (4), add tests. - Add tests for the recursive `__kindof` specifier merge (i.e. properly merge the second `__kindof` in `NSSet<__ki

[PATCH] D33324: [index] Avoid infinite recursion when looking up a dependent name

arphaman created this revision. This is a regression introduced by r302632 . Repository: rL LLVM https://reviews.llvm.org/D33324 Files: include/clang/AST/CXXInheritance.h lib/AST/CXXInheritance.cpp test/Index/Core/index-dependent-source.cpp Index: test/Index/Core/index-dependent-sour

r303358 - [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

Author: kparzysz Date: Thu May 18 12:07:11 2017 New Revision: 303358 URL: http://llvm.org/viewvc/llvm-project?rev=303358&view=rev Log: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource The functions creating LValues propagated information about alignment source. Extend the propagated

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

This revision was automatically updated to reflect the committed changes. Closed by commit rL303358: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource (authored by kparzysz). Changed prior to commit: https://reviews.llvm.org/D33284?vs=99353&id=99457#toc Repository: rL LLVM https

[PATCH] D33304: [clang-tidy] Add a new module Android and a new check for file descriptors.

yawanng marked an inline comment as done. yawanng added inline comments. Comment at: clang-tidy/android/FileDescriptorCheck.cpp:76 +int64_t val = aPInt.getSExtValue(); +if((val & O_CLOEXEC) == 0) + return false; srhines wrote: > Using O_CLOEXEC here

[PATCH] D33324: [index] Avoid infinite recursion when looking up a dependent name

benlangmuir accepted this revision. benlangmuir added a comment. This revision is now accepted and ready to land. LGTM. One stylistic comment, but I'll leave that up to you. Comment at: lib/AST/CXXInheritance.cpp:286 +BaseRecord = nullptr; + else if (Visi

[PATCH] D33304: [WIP][clang-tidy] Add a new module Android and a new check for file descriptors.

aaron.ballman added a comment. In https://reviews.llvm.org/D33304#758624, @srhines wrote: > In https://reviews.llvm.org/D33304#758621, @joerg wrote: > > > I find the use of "must" at the very least inappropriate. If there was no > > use case for not including it, it wouldn't be an option. There

r303366 - [index] Avoid one more crash caused by infinite recursion that happens when

Author: arphaman Date: Thu May 18 13:06:07 2017 New Revision: 303366 URL: http://llvm.org/viewvc/llvm-project?rev=303366&view=rev Log: [index] Avoid one more crash caused by infinite recursion that happens when looking up a dependent name in a record that derives from itself rdar://32273000 Diff

[PATCH] D33324: [index] Avoid infinite recursion when looking up a dependent name

This revision was automatically updated to reflect the committed changes. arphaman marked an inline comment as done. Closed by commit rL303366: [index] Avoid one more crash caused by infinite recursion that happens when (authored by arphaman). Changed prior to commit: https://reviews.llvm.org/D

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz abandoned this revision. kparzysz added a comment. This review is replaced by https://reviews.llvm.org/D33328. Repository: rL LLVM https://reviews.llvm.org/D31885 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz updated this revision to Diff 99467. kparzysz edited subscribers, added: cfe-commits; removed: llvm-commits. kparzysz added a comment. The diff is the same as before, the change is in the subscribers: from llvm-commits to cfe-commits. Repository: rL LLVM https://reviews.llvm.org/D33

[PATCH] D33329: clang-format: [JS] for await, and fix a crash with for loops.

mprobst created this revision. Herald added a subscriber: klimek. The syntax is actually `for await (const x of y)` (d'oh). This also fixes a crash for `for` tokens not followed by additional tokens. https://reviews.llvm.org/D33329 Files: lib/Format/TokenAnnotator.cpp lib/Format/UnwrappedLi

[PATCH] D33304: [WIP][clang-tidy] Add a new module Android and a new check for file descriptors.

alexfh added a comment. In https://reviews.llvm.org/D33304#758713, @aaron.ballman wrote: > In https://reviews.llvm.org/D33304#758624, @srhines wrote: > > > In https://reviews.llvm.org/D33304#758621, @joerg wrote: > > > > > I find the use of "must" at the very least inappropriate. If there was no

Re: r303224 - [modules] When creating a declaration, cache its owning module immediately

Thanks for the awesome testcase, taking a look now. On 18 May 2017 at 07:15, Raphael Isemann wrote: > Hi, > > this is breaking our STL module builds. Can we revert this? > > We also have a minimal reproducer for our crash here > http://teemperor.de/pub/stl_merging_issue.zip > > - Raphael > > 201

[PATCH] D33304: [WIP][clang-tidy] Add a new module Android and a new check for file descriptors.

Eugene.Zelenko added inline comments. Comment at: clang-tidy/android/AndroidTidyModule.cpp:15 +#include "../ClangTidyModuleRegistry.h" +#include "../readability/BracesAroundStatementsCheck.h" +#include "../readability/FunctionSizeCheck.h" Are readability headers

r303370 - CodeGen: Cast alloca to expected address space

Author: yaxunl Date: Thu May 18 13:51:09 2017 New Revision: 303370 URL: http://llvm.org/viewvc/llvm-project?rev=303370&view=rev Log: CodeGen: Cast alloca to expected address space Alloca always returns a pointer in alloca address space, which may be different from the type defined by the language

[PATCH] D32248: CodeGen: Cast alloca to expected address space

This revision was automatically updated to reflect the committed changes. Closed by commit rL303370: CodeGen: Cast alloca to expected address space (authored by yaxunl). Changed prior to commit: https://reviews.llvm.org/D32248?vs=99204&id=99479#toc Repository: rL LLVM https://reviews.llvm.o

[PATCH] D33333: Emit warning when throw exception in destruct or dealloc functions which has a (possible implicit) noexcept specifier

jyu2 created this revision. Throwing in the destructor is not good (C++11 change try to not allow see below). But in reality, those codes are exist. C++11 [class.dtor]p3: A declaration of a destructor that does not have an exception-specification is implicitly considered to have the same e

[PATCH] D33304: [WIP][clang-tidy] Add a new module Android and a new check for file descriptors.

aaron.ballman added a comment. In https://reviews.llvm.org/D33304#758808, @alexfh wrote: > In https://reviews.llvm.org/D33304#758713, @aaron.ballman wrote: > > > In https://reviews.llvm.org/D33304#758624, @srhines wrote: > > > > > In https://reviews.llvm.org/D33304#758621, @joerg wrote: > > > > >

r303372 - Fix the location of "missing '; '" suggestions after annotation tokens.

Author: rsmith Date: Thu May 18 14:21:48 2017 New Revision: 303372 URL: http://llvm.org/viewvc/llvm-project?rev=303372&view=rev Log: Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instea

r303373 - When we enter a module within a linkage specification, switch the linkage

Author: rsmith Date: Thu May 18 14:34:55 2017 New Revision: 303373 URL: http://llvm.org/viewvc/llvm-project?rev=303373&view=rev Log: When we enter a module within a linkage specification, switch the linkage specification and the TU to the new module. This is necessary to get the module ownership

Re: r303224 - [modules] When creating a declaration, cache its owning module immediately

I see, the problem is that template parameters are temporarily put in the wrong DeclContext while the rest of the declaration is being parsed (and thus end up temporarily owned by the wrong module). Fixed in r303373. On 18 May 2017 at 11:52, Richard Smith wrote: > Thanks for the awesome testcase

Re: r303224 - [modules] When creating a declaration, cache its owning module immediately

Thanks for the quick fix! 2017-05-18 21:48 GMT+02:00 Richard Smith : > I see, the problem is that template parameters are temporarily put in the > wrong DeclContext while the rest of the declaration is being parsed (and > thus end up temporarily owned by the wrong module). Fixed in r303373. > > On

[PATCH] D33304: [WIP][clang-tidy] Add a new module Android and a new check for file descriptors.

yawanng added a comment. In https://reviews.llvm.org/D33304#758871, @aaron.ballman wrote: > In https://reviews.llvm.org/D33304#758808, @alexfh wrote: > > > In https://reviews.llvm.org/D33304#758713, @aaron.ballman wrote: > > > > > In https://reviews.llvm.org/D33304#758624, @srhines wrote: > > > >

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

Local build: r302937 no issue, r302938 has issue. On Thu, May 18, 2017 at 7:23 AM Dehao Chen wrote: > Could you give some context on how r302938 is related to this? > > Thanks, > Dehao > > On Wed, May 17, 2017 at 11:14 PM, Vitaly Buka > wrote: > >> +Dehao Chen >> it started from r302938 >> >>

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

What's the issue? Build breaking? Performance regression? It's not clear from the limit info in this thread... Dehao On Thu, May 18, 2017 at 1:02 PM, Vitaly Buka wrote: > Local build: r302937 no issue, r302938 has issue. > > On Thu, May 18, 2017 at 7:23 AM Dehao Chen wrote: > >> Could you give

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

Clang produces some confusing macro errors. According to Richard it's miscompilation: https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg57270.html On Thu, May 18, 2017 at 1:14 PM Dehao Chen wrote: > What's the issue? Build breaking? Performance regression? It's not clear > from the limi

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

On 18 May 2017 1:14 pm, "Dehao Chen" wrote: What's the issue? Build breaking? Performance regression? It's not clear from the limit info in this thread... r302938 introduced or exposed a miscompile that causes a stage2 msan build of Clang to misbehave: http://lab.llvm.org:8011/builders/sanitiz

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

On 18 May 2017 1:19 pm, "Richard Smith" wrote: On 18 May 2017 1:14 pm, "Dehao Chen" wrote: What's the issue? Build breaking? Performance regression? It's not clear from the limit info in this thread... r302938 introduced or exposed a miscompile that causes a stage2 msan build of Clang to misb

[clang-tools-extra] r303376 - [clangd] Make formatting.test asynchronous again.

Author: d0k Date: Thu May 18 15:10:04 2017 New Revision: 303376 URL: http://llvm.org/viewvc/llvm-project?rev=303376&view=rev Log: [clangd] Make formatting.test asynchronous again. This test doesn't rely on the order of asynchronous messages, enable threads so we have at least some coverage for th

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

My understanding is that r302938 makes clang generate incorrect code (clang itself), which lead to unexpected clang behavior. Is it correct? If yes, how can I reproduce this issue so that I can try to triage/fix the problem? Thanks, Dehao On Thu, May 18, 2017 at 1:22 PM, Richard Smith wrote: >

[PATCH] D33333: Emit warning when throw exception in destruct or dealloc functions which has a (possible implicit) noexcept specifier

rnk added a comment. I think we should consider generalizing this to throwing from any noexcept function. We could add a special case diagnostic to explain that destructors and delete operators are noexcept by default in C++11. It's also probably a good idea to silence this warning if there are

[PATCH] D33333: Emit warning when throw exception in destruct or dealloc functions which has a (possible implicit) noexcept specifier

lebedev.ri added a comment. Relevant https://reviews.llvm.org/D31370, https://reviews.llvm.org/D19201 https://reviews.llvm.org/D3 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33339: Fix valid-for-expr ellipses eaten as invalid decl

hubert.reinterpretcast created this revision. The trial parse for declarative syntax accepts an invalid pack declaration syntax, which is ambiguous with valid pack expansions of expressions. This commit restricts the invalid pack declaration syntax to avoid mistaking valid pack expansions as in

r303382 - clang-format: [JS] for await, and fix a crash with for loops.

Author: mprobst Date: Thu May 18 16:19:29 2017 New Revision: 303382 URL: http://llvm.org/viewvc/llvm-project?rev=303382&view=rev Log: clang-format: [JS] for await, and fix a crash with for loops. Summary: The syntax is actually `for await (const x of y)` (d'oh). This also fixes a crash for `for`

[PATCH] D33329: clang-format: [JS] for await, and fix a crash with for loops.

This revision was automatically updated to reflect the committed changes. Closed by commit rL303382: clang-format: [JS] for await, and fix a crash with for loops. (authored by mprobst). Changed prior to commit: https://reviews.llvm.org/D33329?vs=99468&id=99496#toc Repository: rL LLVM https:

[PATCH] D33340: [libcxx] [test] Add string nullptr asserts to erase functions.

BillyONeal created this revision. In my perf overhaul for MSVC++'s basic_string I wrote the null at data[oldsize] instead of data[newsize]; adding asserts to catch that bug. https://reviews.llvm.org/D33340 Files: test/std/strings/basic.string/string.modifiers/string_erase/iter.pass.cpp tes

[PATCH] D19201: [clang-tidy] misc-throw-with-noexcept

sbarzowski updated this revision to Diff 99500. sbarzowski marked 3 inline comments as done. sbarzowski added a comment. Docs and cosmetic issues https://reviews.llvm.org/D19201 Files: clang-tidy/misc/CMakeLists.txt clang-tidy/misc/MiscTidyModule.cpp clang-tidy/misc/ThrowWithNoexceptCheck

[PATCH] D33339: Fix valid-for-expr ellipses eaten as invalid decl

hubert.reinterpretcast added inline comments. Comment at: lib/Parse/ParseTentative.cpp:542 + (Tok.is(tok::greatergreater) || + (Tok.is(tok::ellipsis) && + NextToken().isOneOf(tok::greater, tok::greatergreater, Th

[PATCH] D19201: [clang-tidy] misc-throw-with-noexcept

sbarzowski updated this revision to Diff 99502. sbarzowski marked 8 inline comments as done. sbarzowski added a comment. Removed unnecessary colon from message https://reviews.llvm.org/D19201 Files: clang-tidy/misc/CMakeLists.txt clang-tidy/misc/MiscTidyModule.cpp clang-tidy/misc/ThrowWit

Re: r302966 - Remove unused tracking of owning module for MacroInfo objects.

On 18 May 2017 at 13:28, Dehao Chen wrote: > My understanding is that r302938 makes clang generate incorrect code > (clang itself), which lead to unexpected clang behavior. Is it correct? > Yes, I believe so, specifically when the stage2 clang is built with -fsanitize=memory and (I think) -O2.

[PATCH] D15994: Allow for unfinished #if blocks in preambles.

rsmith accepted this revision. rsmith added a comment. Some comments, but I'm happy for you to go ahead and commit after addressing them. Thanks! Comment at: include/clang/Lex/Preprocessor.h:2004 + ArrayRef getPreambleConditionalStack() const + { return PreambleConditionalSt

[PATCH] D33333: Emit warning when throw exception in destruct or dealloc functions which has a (possible implicit) noexcept specifier

jyu2 updated this revision to Diff 99517. jyu2 added a comment. Reid, Thank you so much for your comments. I upload new patch to address your suggestion. 1> Emit warning for throw exception in all noexcept function. And special diagnostic note for destructor and delete operators. 2> Silence th

[PATCH] D33339: Fix valid-for-expr ellipses eaten as invalid decl

rsmith added a comment. Should I assume our "misplaced ellipsis" diagnostic requires that we disambiguate the ill-formed ellipsis-after-declarator-id as a declaration in some cases? If so, do we have tests for that somewhere? Comment at: include/clang/Parse/Parser.h:2138 + T

[PATCH] D32146: PR32476: __nop_locale_mgmt.h not needed with newlib 2.5+

bcraig added inline comments. Comment at: include/support/newlib/xlocale.h:20 +#if defined(__NEWLIB__) && (__NEWLIB__ == 2) \ +&& defined(__NEWLIB_MINOR__) && (__NEWLIB_MINOR__ >= 5) \ +&& (!defined(__POSIX_VISIBLE) || (__POSIX_VISIBLE < 200809)) orivej w

r303398 - When a type-id is unexpectedly given a name, assume that the name is unrelated

Author: rsmith Date: Thu May 18 20:54:59 2017 New Revision: 303398 URL: http://llvm.org/viewvc/llvm-project?rev=303398&view=rev Log: When a type-id is unexpectedly given a name, assume that the name is unrelated syntax unless we have a reason to think otherwise. This improves error recovery in a

[PATCH] D33197: [libclang] [OpenCL] Expose more OpenCL CIndex types

yaxunl added inline comments. Comment at: include/clang-c/Index.h:3080 + CXType_Elaborated = 119, + CXType_Pipe = 120, + CXType_OCLImage1dRO = 121, Can we have a doxygen comment about the OpenCL types? https://reviews.llvm.org/D33197 _

[PATCH] D33339: Fix valid-for-expr ellipses eaten as invalid decl

hubert.reinterpretcast added a comment. In https://reviews.llvm.org/D9#759125, @rsmith wrote: > Should I assume our "misplaced ellipsis" diagnostic requires that we > disambiguate the ill-formed ellipsis-after-declarator-id as a declarator in > some cases? If so, do we have tests for that s

[PATCH] D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation

ddcc updated this revision to Diff 99521. ddcc added a comment. Fix typo in SymbolCast simplification https://reviews.llvm.org/D28953 Files: include/clang/StaticAnalyzer/Checkers/SValExplainer.h lib/StaticAnalyzer/Core/SValBuilder.cpp lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp lib/St

[PATCH] D28954: [analyzer] Add support for symbolic float expressions

ddcc updated this revision to Diff 99522. ddcc added a comment. Herald added a subscriber: eraman. Rebase, avoid generating floating-point constraints if unsupported by constraint manager https://reviews.llvm.org/D28954 Files: include/clang/StaticAnalyzer/Checkers/Checkers.td include/clang

[PATCH] D33314: clang-format: Add option to remove semicolon at end of namespace

djasper added a comment. Yes, this definitely does not belong in the NamespaceEndCommentsFixer. It has nothing to do with comments. And I am also very skeptical about several things: - Why start here? There are many places where semicolons could be cleaned up. - If we add more of such cleanup f

[PATCH] D32480: clang-format: Add CompactNamespaces option

djasper added inline comments. Comment at: include/clang/Format/Format.h:358 + /// \endcode + bool BinPackNamespaces; + Typz wrote: > djasper wrote: > > This is not bin packing at all. Maybe CompactNamespaces? Or > > SingleLineNamespaces? > > > > Also, could