[PATCH] D67980: [CLANG][BPF] do compile-once run-everywhere relocation for bitfields

yonghong-song updated this revision to Diff 223405. yonghong-song retitled this revision from "[WIP][CLANG][BPF] do compile-once run-everywhere relocation for bitfields" to "[CLANG][BPF] do compile-once run-everywhere relocation for bitfields". yonghong-song edited the summary of this revision.

[PATCH] D67980: [WIP][CLANG][BPF] do compile-once run-everywhere relocation for bitfields

yonghong-song marked an inline comment as done. yonghong-song added inline comments. Comment at: llvm/lib/Target/BPF/BPFCORE.h:17 + enum OffsetRelocKind : uint32_t { +FIELD_ACCESS_OFFSET = 0, +FIELD_EXISTENCE, yonghong-song wrote: > ast wrote: > > why

[PATCH] D67980: [WIP][CLANG][BPF] do compile-once run-everywhere relocation for bitfields

yonghong-song added a comment. > All these names are not added as builtin enum before compilation starts, > right? Do you prefer to have builtin enum? If we do this, we will emit this enum all the time, regardless of whether people uses this builtin or not. Are you worried about API stability?

[PATCH] D67980: [WIP][CLANG][BPF] do compile-once run-everywhere relocation for bitfields

yonghong-song marked 4 inline comments as done and an inline comment as not done. yonghong-song added inline comments. Comment at: llvm/lib/Target/BPF/BPFCORE.h:17 + enum OffsetRelocKind : uint32_t { +FIELD_ACCESS_OFFSET = 0, +FIELD_EXISTENCE, ast

[PATCH] D67980: [WIP][CLANG][BPF] do compile-once run-everywhere relocation for bitfields

ast added inline comments. Comment at: llvm/lib/Target/BPF/BPFCORE.h:17 + enum OffsetRelocKind : uint32_t { +FIELD_ACCESS_OFFSET = 0, +FIELD_EXISTENCE, why ACCESS_OFFSET is necessary? Isn't it the same as BYTE_OFFSET but for non-bitfield? May be single

[PATCH] D68410: [AttrDocs] document always_inline

joerg added a comment. I wonder if we should actually enumerate evil here, i.e. give the situations in which inlining actually fails. As mentioned on IRC, I wonder if we shouldn't aim for the stronger semantics and at least warn by default of any situation that prevents always_inline from

[PATCH] D68539: [clang-tidy] fix for readability-identifier-naming incorrectly fixes variables which become keywords

Daniel599 updated this revision to Diff 223372. Daniel599 added a comment. code fixes according to code-review comments Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68539/new/ https://reviews.llvm.org/D68539 Files:

[PATCH] D65695: Implements CWG 1601 in [over.ics.rank/4.2]

Mordante added a comment. Thanks for the review. Can you commit the patch since I don't have commit access? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65695/new/ https://reviews.llvm.org/D65695 ___ cfe-commits mailing list

[PATCH] D64820: [Sema] Avoids an assertion failure when an invalid conversion declaration is used

Mordante added a comment. Thanks for the review. Can you commit the patch since I don't have commit access? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64820/new/ https://reviews.llvm.org/D64820 ___ cfe-commits mailing list

r373831 - Try to fix sphinx indentation error

Author: rksimon Date: Sat Oct 5 09:08:17 2019 New Revision: 373831 URL: http://llvm.org/viewvc/llvm-project?rev=373831=rev Log: Try to fix sphinx indentation error Modified: cfe/trunk/docs/ReleaseNotes.rst Modified: cfe/trunk/docs/ReleaseNotes.rst URL:

r373829 - RewriteObjC - silence static analyzer getAs<> null dereference warnings. NFCI.

Author: rksimon Date: Sat Oct 5 06:42:14 2019 New Revision: 373829 URL: http://llvm.org/viewvc/llvm-project?rev=373829=rev Log: RewriteObjC - silence static analyzer getAs<> null dereference warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be able

[PATCH] D68539: [clang-tidy] fix for readability-identifier-naming incorrectly fixes variables which become keywords

Eugene.Zelenko added inline comments. Comment at: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:865 + auto = Decl->getASTContext().Idents; + auto CheckNewIdentifier = Idents.find(Fixup); Please don't use auto when type is not

[PATCH] D68539: fix for readability-identifier-naming incorrectly fixes variables which become keywords

Daniel599 created this revision. Daniel599 added reviewers: llvm-commits, alexfh, alexfh_. Daniel599 added projects: clang-tools-extra, LLVM. Herald added a project: clang. Herald added a subscriber: cfe-commits. Daniel599 edited the summary of this revision. This patch fixes 'Bug 41120'

r373828 - [Diagnostics] Highlight expr's source range for -Wbool-operation

Author: xbolva00 Date: Sat Oct 5 06:28:15 2019 New Revision: 373828 URL: http://llvm.org/viewvc/llvm-project?rev=373828=rev Log: [Diagnostics] Highlight expr's source range for -Wbool-operation Warning message looks better; and GCC adds it too. Modified: cfe/trunk/lib/Sema/SemaExpr.cpp

r373825 - Remove redundant !HasDependentValue check. NFCI.

Author: rksimon Date: Sat Oct 5 06:20:51 2019 New Revision: 373825 URL: http://llvm.org/viewvc/llvm-project?rev=373825=rev Log: Remove redundant !HasDependentValue check. NFCI. Fixes cppcheck warning. Modified: cfe/trunk/lib/Sema/SemaStmt.cpp Modified: cfe/trunk/lib/Sema/SemaStmt.cpp URL:

r373826 - TreeTransform - silence static analyzer getAs<> null dereference warnings. NFCI.

Author: rksimon Date: Sat Oct 5 06:20:59 2019 New Revision: 373826 URL: http://llvm.org/viewvc/llvm-project?rev=373826=rev Log: TreeTransform - silence static analyzer getAs<> null dereference warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be

r373827 - SemaTemplate - silence static analyzer getAs<> null dereference warnings. NFCI.

Author: rksimon Date: Sat Oct 5 06:21:08 2019 New Revision: 373827 URL: http://llvm.org/viewvc/llvm-project?rev=373827=rev Log: SemaTemplate - silence static analyzer getAs<> null dereference warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be

r373824 - SemaStmt - silence static analyzer getAs<> null dereference warnings. NFCI.

Author: rksimon Date: Sat Oct 5 06:20:42 2019 New Revision: 373824 URL: http://llvm.org/viewvc/llvm-project?rev=373824=rev Log: SemaStmt - silence static analyzer getAs<> null dereference warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be able to

[PATCH] D68481: [clang-format] [PR27004] omits leading space for noexcept when formatting operator delete()

MyDeveloperDay added inline comments. Comment at: clang/lib/Format/TokenAnnotator.cpp:1617 +if (Tok.Next->isOneOf(tok::kw_noexcept, tok::kw_volatile, tok::kw_const, + tok::kw_throw, tok::l_square, tok::arrow)) + return false;

[PATCH] D68481: [clang-format] [PR27004] omits leading space for noexcept when formatting operator delete()

MyDeveloperDay updated this revision to Diff 223369. MyDeveloperDay marked 2 inline comments as done. MyDeveloperDay added a comment. Add additional override and final keywords CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68481/new/ https://reviews.llvm.org/D68481 Files:

[PATCH] D68255: [X86] Remove AVX/AVX512 check from validateOperandSize, just always accept 512

echristo added a comment. The idea was that we'd have a much more graceful error message as well as a way for the front end to do the diagnosis. The code is being called out of SemaStmtAsm.cpp and I'm pretty sure we can probably accumulate the target attributes there? -eric CHANGES SINCE

[PATCH] D68473: [clang-format] SpacesInSquareBrackets should affect lambdas with parameters too

This revision was automatically updated to reflect the committed changes. Closed by commit rL373821: [clang-format] SpacesInSquareBrackets should affect lambdas with parameters too (authored by paulhoad, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits.

[PATCH] D68473: [clang-format] SpacesInSquareBrackets should affect lambdas with parameters too

MyDeveloperDay added inline comments. Comment at: clang/lib/Format/TokenAnnotator.cpp:2613 + TT_StructuredBindingLSquare, + TT_LambdaLSquare) && Style.SpacesInSquareBrackets && Right.isNot(tok::r_square));

r373821 - [clang-format] SpacesInSquareBrackets should affect lambdas with parameters too

Author: paulhoad Date: Sat Oct 5 02:55:23 2019 New Revision: 373821 URL: http://llvm.org/viewvc/llvm-project?rev=373821=rev Log: [clang-format] SpacesInSquareBrackets should affect lambdas with parameters too Summary: This patch makes the `SpacesInSquareBrackets` setting also apply to C++

r373818 - [NFCI] Slightly improve warning message

Author: xbolva00 Date: Sat Oct 5 01:09:06 2019 New Revision: 373818 URL: http://llvm.org/viewvc/llvm-project?rev=373818=rev Log: [NFCI] Slightly improve warning message Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td cfe/trunk/test/SemaCXX/warn-xor-as-pow.cpp Modified:

r373817 - [Diagnostics] Use Expr::isKnownToHaveBooleanValue() to check bitwise negation of bool in languages without a bool type

Author: xbolva00 Date: Sat Oct 5 01:02:11 2019 New Revision: 373817 URL: http://llvm.org/viewvc/llvm-project?rev=373817=rev Log: [Diagnostics] Use Expr::isKnownToHaveBooleanValue() to check bitwise negation of bool in languages without a bool type Thanks for this advice, Richard Trieu!

[PATCH] D68520: [cmake] Fix clang builds with BUILD_SHARED=ON and CLANG_LINK_CLANG_DYLIB=ON

mgorny added a comment. Got me a while to understand what you're saying. It's all high magic but looks reasonable enough. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68520/new/ https://reviews.llvm.org/D68520

[PATCH] D63397: [clangd] Detect C++ for extension-less source files in vscode extension

malaperle added a comment. In D63397#1696000 , @malaperle wrote: > "Extend our extension to support detecting these files as C++ files based on > the first > line (-*- C++ -*-), it will make clangd work on C++ standard headers > (e.g. iostream)." > >