[PATCH] D48531: [CodeGen] Provide source locations for UBSan type checks when emitting constructor calls.

This revision was automatically updated to reflect the committed changes. Closed by commit rL335445: [CodeGen] Provide source locations for UBSan type checks when emitting… (authored by ikudrin, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.ll

r335445 - [CodeGen] Provide source locations for UBSan type checks when emitting constructor calls.

Author: ikudrin Date: Sun Jun 24 22:48:04 2018 New Revision: 335445 URL: http://llvm.org/viewvc/llvm-project?rev=335445&view=rev Log: [CodeGen] Provide source locations for UBSan type checks when emitting constructor calls. Differential Revision: https://reviews.llvm.org/D48531 Added: cfe/t

[PATCH] D48456: [Fixed Point Arithmetic] Casting between fixed point types and other arithmetic types

rjmccall added inline comments. Comment at: include/clang/AST/ASTContext.h:1954 + llvm::APInt getFixedPointMin(QualType Ty) const; + llvm::APInt getFixedPointOne(QualType Ty) const; Are these opaque bit-patterns? I think there should be a type which abstract

[PATCH] D48531: [CodeGen] Provide source locations for UBSan type checks when emitting constructor calls.

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. LGTM. Repository: rC Clang https://reviews.llvm.org/D48531 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/c

[PATCH] D48531: [CodeGen] Provide source locations for UBSan type checks when emitting constructor calls.

ikudrin created this revision. ikudrin added reviewers: rsmith, rjmccall. ikudrin added a project: clang. Herald added subscribers: JDevlieghere, aprantl. At the moment. when generating UBSan diagnostics for these cases, we rely on the corresponding debug information, which might be absent, and, a

[PATCH] D48462: [X86] Update handling in CGBuiltin to be tolerant of out of range immediates.

craig.topper closed this revision. craig.topper added a comment. Committed in r335308, https://reviews.llvm.org/D48462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47459: [ASTImporter] Eliminated some unittest warnings.

a_sidorin added a comment. Hello Balázs, The patch is mostly LG now, thank you! Comment at: unittests/AST/ASTImporterTest.cpp:495 " struct s { int x; long y; unsigned z; }; " - " (struct s){ 42, 0L, 1U }; }", + " (void) (struct s){ 42,

[PATCH] D47367: [ASTImporter] Add ms compatibility to tests

a_sidorin accepted this revision. a_sidorin added a comment. This revision is now accepted and ready to land. LGTM, thank you! Could you describe the refactoring in the commit message? Comment at: unittests/AST/ASTImporterTest.cpp:212 + /// The verification is done by running

[PATCH] D47532: [ASTImporter] Import the whole redecl chain of functions

a_sidorin accepted this revision. a_sidorin added a comment. This revision is now accepted and ready to land. Hi Gabor, The patch LG, thank you for addressing my questions. Just some stylish nits. Comment at: unittests/AST/ASTImporterTest.cpp:2021 + +TEST_P(ImportFriendFunctio

[PATCH] D47534: [ASTImporter] Add new tests about templated-described swing

a_sidorin accepted this revision. a_sidorin added a comment. This revision is now accepted and ready to land. Hi Gabor, Tests are always welcome. This patch is OK and can be committed after fixing nits without additional approval. Comment at: unittests/AST/ASTImporterTest.cpp

[PATCH] D47450: [ASTImporter] Use InjectedClassNameType at import of templated record.

a_sidorin added a comment. Hello Balázs, Please clang-format the tests and delete injected-class-name-decl-1. Don't see any other issues. Comment at: lib/AST/ASTImporter.cpp:2132 +if (!DCXX->isInjectedClassName()) { + // In a record describing a template the

[PATCH] D44143: [clang-tidy] Create properly seeded random generator check

boga95 marked 12 inline comments as done. boga95 added a comment. I think I resolved all of the comments. Do I forget anything? Comment at: clang-tidy/cert/CERTTidyModule.cpp:44 "cert-dcl54-cpp"); -CheckFactories.registerCheck( -"cert-dcl58-cpp"); + Che

[PATCH] D48522: [analyzer] Highlight c_str() call in DanglingInternalBuffer checker

xazax.hun accepted this revision. xazax.hun added inline comments. Comment at: lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp:41 +// Tracked pointer to a buffer. +SymbolRef Sym; + I am fine with this as is, but I prefer self documenting cod

[PATCH] D48522: [analyzer] Highlight c_str() call in DanglingInternalBuffer checker

rnkovacs updated this revision to Diff 152616. rnkovacs marked 4 inline comments as done. rnkovacs added a comment. Thanks! Addressed comments. https://reviews.llvm.org/D48522 Files: lib/StaticAnalyzer/Checkers/AllocationState.h lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp

[PATCH] D48460: [analyzer] Fix invalidation on C++ const methods.

xazax.hun accepted this revision. xazax.hun added a comment. This revision is now accepted and ready to land. LGTM! Repository: rC Clang https://reviews.llvm.org/D48460 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org

[PATCH] D48521: [analyzer] Highlight container object destruction in MallocChecker

xazax.hun accepted this revision. xazax.hun added a comment. LGTM, given that the assert does not fire for the projects you tested on. https://reviews.llvm.org/D48521 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-

[PATCH] D48521: [analyzer] Highlight container object destruction in MallocChecker

rnkovacs updated this revision to Diff 152615. rnkovacs marked 7 inline comments as done. rnkovacs retitled this revision from "[analyzer] Highlight STL object destruction in MallocChecker" to "[analyzer] Highlight container object destruction in MallocChecker". rnkovacs added a comment. Thanks

Re: r335084 - Append new attributes to the end of an AttributeList.

Hi, multiple comments in the code indicate that the attribute order was surprising and probably has lead to bugs, and will lead to bugs in the future. The order had to be explicitly reversed to avoid those. This alone for me this seems a good reason to have the attributes in the order in which the