[PATCH] D41326: [clang-tidy] Added diagnostics about incorrect usage of NOLINT comment

xgsa marked 3 inline comments as done. xgsa added inline comments. Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:339 std::unique_ptr OptionsProvider) : DiagEngine(nullptr), OptionsProvider(std::move(OptionsProvider)), + Profile(nullptr), E

[PATCH] D41217: [Concepts] Concept Specialization Expressions

faisalv added inline comments. Comment at: lib/Parse/ParseExpr.cpp:223 ExprResult Parser::ParseConstraintExpression() { - // FIXME: this may erroneously consume a function-body as the braced - // initializer list of a compound literal - // - // FIXME: this may erroneously co

[PATCH] D41326: [clang-tidy] Added diagnostics about incorrect usage of NOLINT comment

Eugene.Zelenko added inline comments. Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:169 + } +private: + SmallVector CheckNames; Please separate with empty line. Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:170 +private: +

[PATCH] D41326: [clang-tidy] Added diagnostics about incorrect usage of NOLINT comment

xgsa updated this revision to Diff 127260. xgsa added a comment. A few minor coding style fixes. https://reviews.llvm.org/D41326 Files: clang-tidy/ClangTidy.cpp clang-tidy/ClangTidyDiagnosticConsumer.cpp clang-tidy/ClangTidyDiagnosticConsumer.h test/clang-tidy/nolint-usage.cpp test/cl

[PATCH] D41326: [clang-tidy] Added diagnostics about incorrect usage of NOLINT comment

xgsa created this revision. xgsa added reviewers: aaron.ballman, alexfh. xgsa added a project: clang-tools-extra. Herald added subscribers: cfe-commits, xazax.hun. As discussed in the previous review [1], diagnostics about incorrect usage of NOLINT comment was added, i.e..: - usage of NOLINT wit

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

bcain added a comment. In https://reviews.llvm.org/D41316#957598, @jroelofs wrote: > I'd much rather provide no implementation than one that lies. Broken builds > are much safer than problems at runtime. Agreed! Especially the problems caused by a predictable random seed. Repository: rCXX

[libcxx] r320925 - [libcxx] Add WebAssembly support

Author: sbc Date: Sat Dec 16 10:59:50 2017 New Revision: 320925 URL: http://llvm.org/viewvc/llvm-project?rev=320925&view=rev Log: [libcxx] Add WebAssembly support It turns out that this is the only change required in libcxx for it to compile with the new `wasm32-unknown-unknown-wasm` target recen

[PATCH] D41073: Wasm: add support in libcxx

This revision was automatically updated to reflect the committed changes. Closed by commit rL320925: [libcxx] Add WebAssembly support (authored by sbc, committed by ). Changed prior to commit: https://reviews.llvm.org/D41073?vs=127242&id=127251#toc Repository: rL LLVM https://reviews.llvm.o

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

weimingz added a comment. Does it make sense to provide an implementation based on C99 rand? like #ifdef _LIBCPP_USING_C99_RANDOM srand(0), rand() Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commi

[PATCH] D40937: [clang-tidy] Infinite loop checker

xazax.hun added a comment. I think, while the analyzer is more suitable for certain kinds of checks that require deep analysis, it is still useful to have quicker syntactic checks that can easily identify problems that are the results of typos or incorrectly modified copy and pasted code. I thi

[PATCH] D41151: [analyzer] Adding LoopContext and improve loop modeling

xazax.hun added a comment. Just to be sure, this is just a refactoring to make this cleaner or you expect this to have other effects as well, like better performance? https://reviews.llvm.org/D41151 ___ cfe-commits mailing list cfe-commits@lists.ll

[PATCH] D40560: [analyzer] WIP: Get construction into `operator new` running in simple cases.

xazax.hun added a comment. In https://reviews.llvm.org/D40560#947514, @NoQ wrote: > Replaced the live expression hack with a slightly better approach. It doesn't > update the live variables analysis to take `CFGNewAllocator` into account, > but at least tests now pass. > > In order to keep the

[PATCH] D41250: [analyzer] Model implied cast around operator new().

xazax.hun accepted this revision. xazax.hun added a comment. This revision is now accepted and ready to land. The code looks good to me. But the best way to verify these kinds of changes to see how the results change on large projects after applying the patch. https://reviews.llvm.org/D41250

[PATCH] D41266: [analyzer] With c++-allocator-inlining, fix memory space for operator new pointers.

xazax.hun accepted this revision. xazax.hun added a comment. This revision is now accepted and ready to land. In the future, we might want to model the standard placement new and return a symbol with the correct SpaceRegion (i.e.: the space region of the argument). Comment at:

[PATCH] D39812: [Driver, CodeGen] pass through and apply -fassociative-math

This revision was automatically updated to reflect the committed changes. Closed by commit rL320920: [Driver, CodeGen] pass through and apply -fassociative-math (authored by spatel, committed by ). Changed prior to commit: https://reviews.llvm.org/D39812?vs=122158&id=127245#toc Repository: r

r320920 - [Driver, CodeGen] pass through and apply -fassociative-math

Author: spatel Date: Sat Dec 16 08:11:17 2017 New Revision: 320920 URL: http://llvm.org/viewvc/llvm-project?rev=320920&view=rev Log: [Driver, CodeGen] pass through and apply -fassociative-math There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF: 1. In th

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

jroelofs added a comment. I say that because there are contexts where it is **absolutely critical** that https://xkcd.com/221/ not be the implementation of an RNG. Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing l

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

jroelofs added a comment. I'd much rather provide no implementation than one that lies. Broken builds are much safer than problems at runtime. Repository: rCXX libc++ https://reviews.llvm.org/D41316 ___ cfe-commits mailing list cfe-commits@lists

[PATCH] D41306: [clangd] Update documentation page with new features, instructions

jkorous-apple accepted this revision. jkorous-apple added a comment. This revision is now accepted and ready to land. LGTM Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D41306 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D41073: Wasm: add support in libcxx

ncw updated this revision to Diff 127242. ncw added a comment. Herald added a subscriber: krytarowski. Although Dan has already reviewed, I've sneakily added in another change here to help compilation against Musl. Musl is Linux-only, or rather, provides the linux ABI. For Wasm, `__linux` isn't

[PATCH] D41316: [libcxx] Allow random_device to be built optionally

Quuxplusone added a comment. I keep seeing patches go by for other targets where they're just implementing `random_device` for their target. It doesn't *have* to be based on an actual /dev/urandom. You can see all the other options under #ifdefs in this file: getentropy, /dev/random, nacl_secur

[PATCH] D41308: [analyser] different.BitwiseOpBoolArg checker implementation

JonasToth added a comment. That check is similar to 'hicpp-signed-bitwise' in clang-tidy. Maybe it could live there and extend it? Repository: rC Clang https://reviews.llvm.org/D41308 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http:

r320919 - [X86] Implement kand/kandn/kor/kxor/kxnor/knot intrinsics using native IR.

Author: ctopper Date: Sat Dec 16 00:26:22 2017 New Revision: 320919 URL: http://llvm.org/viewvc/llvm-project?rev=320919&view=rev Log: [X86] Implement kand/kandn/kor/kxor/kxnor/knot intrinsics using native IR. Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp cfe/trunk/test/CodeGen/avx512f-bui