[clang] [lldb] Use CLANG_RESOURCE_DIR more consistently (PR #103388)
https://github.com/bulbazord approved this pull request. The LLDB changes look good to me. I can't speak for the clang portions but fwiw I think they look ok too. https://github.com/llvm/llvm-project/pull/103388 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [llvm] [llvm][TargetParser] Return StringMap from getHostCPUFeatures (PR #97824)
https://github.com/bulbazord approved this pull request. LGTM, thanks! https://github.com/llvm/llvm-project/pull/97824 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [llvm] [llvm][TargetParser] Return StringMap from getHostCPUFeatures (PR #97824)
@@ -47,13 +47,12 @@ namespace sys {
/// The particular format of the names are target dependent, and suitable for
/// passing as -mattr to the target which matches the host.
///
- /// \param Features - A string mapping feature names to either
- /// true (if enabled) or false (if disabled). This routine makes no
guarantees
- /// about exactly which features may appear in this map, except that they are
- /// all valid LLVM feature names.
- ///
- /// \return - True on success.
- bool getHostCPUFeatures(StringMap &Features);
+ /// \return - A string map mapping feature names to either true (if enabled)
+ /// or false (if disabled). This routine makes no guarantees about exactly
+ /// which features may appear in this map, except that they are all valid
LLVM
+ /// feature names. The map can be empty, for example if feature detection
+ /// fails.
+ StringMap getHostCPUFeatures();
bulbazord wrote:
While we're here, maybe the return type should be marked `const`? This is a
map, and `operator[]` is notoriously easy to mess up with maps. This might save
somebody a big headache down the line.
https://github.com/llvm/llvm-project/pull/97824
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [llvm] [llvm][TargetParser] Return optional from getHostCPUFeatures (PR #97824)
https://github.com/bulbazord commented: >From an API standpoint, there doesn't actually seem to be a huge difference >between an empty StringMap and an optional with an empty string map in it >right? Why not return a map every time? https://github.com/llvm/llvm-project/pull/97824 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)
https://github.com/bulbazord requested changes to this pull request. Hmm, actually, I'm not so sure about this change anymore. I went through PEP8 again and saw this: ``` Don’t compare boolean values to True or False using ==: # Correct: if greeting: # Wrong: if greeting == True: Worse: # Wrong: if greeting is True: ``` This doesn't seem like the right change then, no? https://github.com/llvm/llvm-project/pull/91858 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)
https://github.com/bulbazord approved this pull request. LGTM The PR summary is empty, but it looks like the commit message has an explanation for this change, so that's fine. https://github.com/llvm/llvm-project/pull/91858 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)
bulbazord wrote: LLDB changes look fine. https://github.com/llvm/llvm-project/pull/90391 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3804: lacking () for c… (PR #90391)
bulbazord wrote: > > Please update the PR subject as its a lot more than just X86AsmParser.cpp > > Hi @RKSimon > > All the issues mentioned are fixed. The title of the PR is misleading. The > title is the same as the issue (#85868) it corresponds to. Got a look to > other PR's and I thought that this is the usual naming convention. Please > refer to the > [commit](https://github.com/llvm/llvm-project/pull/90391/commits/54c6c6b7d71f5ff293412f5f91e9f880480284f8) > and you will see all the modified files. Commit titles should accurately reflect a change. Your change modifies more than just X86AsmParser.cpp, so reading the commit title alone might lead one to believe that's all that changed. But it's not, you changed many things across the code base (even if the changes are all of the same kind). A more accurate title might be something like: `Add clarifying parenthesis around non-trivial conditions in ternary expressions`. https://github.com/llvm/llvm-project/pull/90391 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 266ec80 - [clang][DebugInfo] Respect fmodule-file-home-is-cwd in skeleton CUs for clang modules
Author: Alex Langford
Date: 2022-10-04T11:25:43-07:00
New Revision: 266ec801fb23f9f5f1d61ca9466e0805fbdb78a7
URL:
https://github.com/llvm/llvm-project/commit/266ec801fb23f9f5f1d61ca9466e0805fbdb78a7
DIFF:
https://github.com/llvm/llvm-project/commit/266ec801fb23f9f5f1d61ca9466e0805fbdb78a7.diff
LOG: [clang][DebugInfo] Respect fmodule-file-home-is-cwd in skeleton CUs for
clang modules
When -fmodule-file-home-is-cwd and the path to the PCM is relative, we
shouldn't assume that the path to the PCM is relative to the modulemap
that produced it. To respect the option -fmodule-file-home-is-cwd, we
should assume the path is relative to the current working directory.
Reviewed By: rmaz
Differential Revision: https://reviews.llvm.org/D134911
Added:
Modified:
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/Modules/module-file-home-is-cwd.m
Removed:
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 35432fa98e590..aa02821aa971b 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2768,8 +2768,12 @@ llvm::DIModule
*CGDebugInfo::getOrCreateModuleRef(ASTSourceDescriptor Mod,
llvm::DIBuilder DIB(CGM.getModule());
SmallString<0> PCM;
-if (!llvm::sys::path::is_absolute(Mod.getASTFile()))
- PCM = Mod.getPath();
+if (!llvm::sys::path::is_absolute(Mod.getASTFile())) {
+ if (CGM.getHeaderSearchOpts().ModuleFileHomeIsCwd)
+PCM = getCurrentDirname();
+ else
+PCM = Mod.getPath();
+}
llvm::sys::path::append(PCM, Mod.getASTFile());
DIB.createCompileUnit(
TheCU->getSourceLanguage(),
diff --git a/clang/test/Modules/module-file-home-is-cwd.m
b/clang/test/Modules/module-file-home-is-cwd.m
index 4f79c5abd9ccd..57f8856406484 100644
--- a/clang/test/Modules/module-file-home-is-cwd.m
+++ b/clang/test/Modules/module-file-home-is-cwd.m
@@ -1,8 +1,22 @@
// RUN: cd %S
-// RUN: %clang_cc1 -fmodules -fno-implicit-modules -fmodule-file-home-is-cwd
-fmodule-name=libA -emit-module Inputs/normal-module-map/module.map -o
%t/mod.pcm
+// RUN: %clang_cc1 -x objective-c -fmodules -fno-implicit-modules \
+// RUN: -fmodule-file-home-is-cwd -fmodule-name=libA -emit-module \
+// RUN: -fmodules-embed-all-files %S/Inputs/normal-module-map/module.map \
+// RUN: -o %t/mod.pcm
// RUN: llvm-bcanalyzer --dump --disable-histogram %t/mod.pcm | FileCheck %s
// CHECK: blob data =
'Inputs{{/|\\}}normal-module-map{{/|\\}}module.map'
// CHECK: blob data =
'Inputs{{/|\\}}normal-module-map{{/|\\}}a2.h'
// CHECK: blob data =
'Inputs{{/|\\}}normal-module-map{{/|\\}}a1.h'
// CHECK-NOT: MODULE_DIRECTORY
+
+@import libA;
+
+// RUN: cd %t
+// RUN: %clang_cc1 -x objective-c -fmodules -fno-implicit-modules
-debug-info-kind=limited \
+// RUN: -debugger-tuning=lldb -dwarf-ext-refs -fmodule-file-home-is-cwd \
+// RUN: -fmodule-map-file=%S/Inputs/normal-module-map/module.map \
+// RUN: -fmodule-file=libA=mod.pcm -emit-llvm -o %t-mod.ll %s
+// RUN: cat %t-mod.ll | FileCheck %s --check-prefix=SKELETON
+
+// SKELETON: !DICompileUnit(language: DW_LANG_ObjC, {{.*}},
splitDebugFilename: "mod.pcm"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] c57f034 - [clang][Sema] Add flag to LookupName to force C/ObjC codepath
Author: Alex Langford
Date: 2022-04-19T12:57:14-07:00
New Revision: c57f03415f9668f942802ff7108410d57c2b10da
URL:
https://github.com/llvm/llvm-project/commit/c57f03415f9668f942802ff7108410d57c2b10da
DIFF:
https://github.com/llvm/llvm-project/commit/c57f03415f9668f942802ff7108410d57c2b10da.diff
LOG: [clang][Sema] Add flag to LookupName to force C/ObjC codepath
Motivation: The intent here is for use in Swift.
When building a clang module for swift consumption, swift adds an
extension block to the module for name lookup purposes. Swift calls
this a SwiftLookupTable. One purpose that this serves is to handle
conflicting names between ObjC classes and ObjC protocols. They exist in
different namespaces in ObjC programs, but in Swift they would exist in
the same namespace. Swift handles this by appending a suffix to a
protocol name if it shares a name with a class. For example, if you have
an ObjC class named "Foo" and a protocol with the same name, the
protocol would be renamed to "FooProtocol" when imported into swift.
When constructing the previously mentioned SwiftLookupTable, we use
Sema::LookupName to look up name conflicts for the previous problem.
By this time, the Parser has long finished its job so the call to
LookupName gets nullptr for its Scope (TUScope will be nullptr
by this point). The C/ObjC path does not have this problem because it
only uses the Scope in specific scenarios. The C++ codepath uses the
Scope quite extensively and will fail early on if the Scope it gets is
null. In our very specific case of looking up ObjC classes with a
specific name, we want to force sema::LookupName to take the C/ObjC
codepath even if C++ or ObjC++ is enabled.
Added:
clang/unittests/Sema/SemaLookupTest.cpp
Modified:
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaLookup.cpp
clang/unittests/Sema/CMakeLists.txt
Removed:
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index e2ae02ea9f76f..d5b73686e84a7 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4252,8 +4252,8 @@ class Sema final {
= NotForRedeclaration);
bool LookupBuiltin(LookupResult &R);
void LookupNecessaryTypesForBuiltin(Scope *S, unsigned ID);
- bool LookupName(LookupResult &R, Scope *S,
- bool AllowBuiltinCreation = false);
+ bool LookupName(LookupResult &R, Scope *S, bool AllowBuiltinCreation = false,
+ bool ForceNoCPlusPlus = false);
bool LookupQualifiedName(LookupResult &R, DeclContext *LookupCtx,
bool InUnqualifiedLookup = false);
bool LookupQualifiedName(LookupResult &R, DeclContext *LookupCtx,
diff --git a/clang/lib/Sema/SemaLookup.cpp b/clang/lib/Sema/SemaLookup.cpp
index 65f5112afee3e..ae3923854b527 100644
--- a/clang/lib/Sema/SemaLookup.cpp
+++ b/clang/lib/Sema/SemaLookup.cpp
@@ -1931,13 +1931,14 @@ NamedDecl
*LookupResult::getAcceptableDeclSlow(NamedDecl *D) const {
/// used to diagnose ambiguities.
///
/// @returns \c true if lookup succeeded and false otherwise.
-bool Sema::LookupName(LookupResult &R, Scope *S, bool AllowBuiltinCreation) {
+bool Sema::LookupName(LookupResult &R, Scope *S, bool AllowBuiltinCreation,
+ bool ForceNoCPlusPlus) {
DeclarationName Name = R.getLookupName();
if (!Name) return false;
LookupNameKind NameKind = R.getLookupKind();
- if (!getLangOpts().CPlusPlus) {
+ if (!getLangOpts().CPlusPlus || ForceNoCPlusPlus) {
// Unqualified name lookup in C/Objective-C is purely lexical, so
// search in the declarations attached to the name.
if (NameKind == Sema::LookupRedeclarationWithLinkage) {
diff --git a/clang/unittests/Sema/CMakeLists.txt
b/clang/unittests/Sema/CMakeLists.txt
index 194b7640b3c19..455c321d541b2 100644
--- a/clang/unittests/Sema/CMakeLists.txt
+++ b/clang/unittests/Sema/CMakeLists.txt
@@ -7,6 +7,7 @@ add_clang_unittest(SemaTests
ExternalSemaSourceTest.cpp
CodeCompleteTest.cpp
GslOwnerPointerInference.cpp
+ SemaLookupTest.cpp
)
clang_target_link_libraries(SemaTests
diff --git a/clang/unittests/Sema/SemaLookupTest.cpp
b/clang/unittests/Sema/SemaLookupTest.cpp
new file mode 100644
index 0..d97b571f6a37c
--- /dev/null
+++ b/clang/unittests/Sema/SemaLookupTest.cpp
@@ -0,0 +1,60 @@
+#include "clang/AST/DeclarationName.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/FrontendAction.h"
+#include "clang/Parse/ParseAST.h"
+#include "clang/Sema/Lookup.h"
+#include "clang/Sema/Sema.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+using namespace clang::tooling;
+
+namespace {
+
+class LookupAction : public ASTFrontendAction {
+ std::unique_ptr
+ CreateASTConsumer(CompilerInstance &CI, StringRef /*Unused*/) override {
+return std::make_unique
[clang] b3f789e - [perf-training] Change profile file pattern string to use %4m instead of %p
Author: Xin-Xin Wang
Date: 2019-12-17T12:12:21-08:00
New Revision: b3f789e037cbfdb1439c01a4eefc9ab9bb0d2c64
URL:
https://github.com/llvm/llvm-project/commit/b3f789e037cbfdb1439c01a4eefc9ab9bb0d2c64
DIFF:
https://github.com/llvm/llvm-project/commit/b3f789e037cbfdb1439c01a4eefc9ab9bb0d2c64.diff
LOG: [perf-training] Change profile file pattern string to use %4m instead of %p
Summary: With %p, each test file that we're using to generate profile data will
make its own profraw file which is around 60 MB in size. If we have a lot of
test files, that quickly uses a lot of space. Use %4m instead to share the
profraw files used to store the profile data. We use 4 here based on the
default value in
https://reviews.llvm.org/source/llvm-github/browse/master/llvm/CMakeLists.txt$604
Reviewers: beanz, phosek, xiaobai, smeenai, vsk
Reviewed By: vsk
Subscribers: vsk, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71585
Added:
Modified:
clang/utils/perf-training/lit.cfg
Removed:
diff --git a/clang/utils/perf-training/lit.cfg
b/clang/utils/perf-training/lit.cfg
index 67a42345da46..e5b7162e5904 100644
--- a/clang/utils/perf-training/lit.cfg
+++ b/clang/utils/perf-training/lit.cfg
@@ -37,5 +37,5 @@ config.substitutions.append( ('%clang_skip_driver', ' %s %s
%s ' % (cc1_wrapper,
config.substitutions.append( ('%clang', ' %s %s ' % (config.clang,
sysroot_flags) ) )
config.substitutions.append( ('%test_root', config.test_exec_root ) )
-config.environment['LLVM_PROFILE_FILE'] = 'perf-training-%p.profraw'
+config.environment['LLVM_PROFILE_FILE'] = 'perf-training-%4m.profraw'
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r372668 - [NFCI] Return PathSensitiveBugReport where appropriate
Author: xiaobai
Date: Mon Sep 23 15:24:47 2019
New Revision: 372668
URL: http://llvm.org/viewvc/llvm-project?rev=372668&view=rev
Log:
[NFCI] Return PathSensitiveBugReport where appropriate
Some compilers have trouble converting unique_ptr to
unique_ptr causing some functions to fail to compile.
Changing the return type of the functions that fail to compile does not
appear to have any issues.
I ran into this issue building with clang 3.8 on Ubuntu 16.04.
Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp?rev=372668&r1=372667&r2=372668&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MacOSKeychainAPIChecker.cpp Mon Sep
23 15:24:47 2019
@@ -113,8 +113,10 @@ private:
const ExplodedNode *getAllocationNode(const ExplodedNode *N, SymbolRef Sym,
CheckerContext &C) const;
- std::unique_ptr generateAllocatedDataNotReleasedReport(
- const AllocationPair &AP, ExplodedNode *N, CheckerContext &C) const;
+ std::unique_ptr
+ generateAllocatedDataNotReleasedReport(const AllocationPair &AP,
+ ExplodedNode *N,
+ CheckerContext &C) const;
/// Mark an AllocationPair interesting for diagnostic reporting.
void markInteresting(PathSensitiveBugReport *R,
@@ -467,7 +469,7 @@ MacOSKeychainAPIChecker::getAllocationNo
return AllocNode;
}
-std::unique_ptr
+std::unique_ptr
MacOSKeychainAPIChecker::generateAllocatedDataNotReleasedReport(
const AllocationPair &AP, ExplodedNode *N, CheckerContext &C) const {
const ADFunctionInfo &FI = FunctionsToTrack[AP.second->AllocatorIdx];
Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp?rev=372668&r1=372667&r2=372668&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp Mon Sep 23
15:24:47 2019
@@ -35,11 +35,11 @@ public:
void checkPreCall(const CallEvent &Call, CheckerContext &C) const;
- std::unique_ptr
+ std::unique_ptr
genReportNullAttrNonNull(const ExplodedNode *ErrorN,
const Expr *ArgE,
unsigned IdxOfArg) const;
- std::unique_ptr
+ std::unique_ptr
genReportReferenceToNullPointer(const ExplodedNode *ErrorN,
const Expr *ArgE) const;
};
@@ -179,7 +179,7 @@ void NonNullParamChecker::checkPreCall(c
C.addTransition(state);
}
-std::unique_ptr
+std::unique_ptr
NonNullParamChecker::genReportNullAttrNonNull(const ExplodedNode *ErrorNode,
const Expr *ArgE,
unsigned IdxOfArg) const {
@@ -204,7 +204,8 @@ NonNullParamChecker::genReportNullAttrNo
return R;
}
-std::unique_ptr
NonNullParamChecker::genReportReferenceToNullPointer(
+std::unique_ptr
+NonNullParamChecker::genReportReferenceToNullPointer(
const ExplodedNode *ErrorNode, const Expr *ArgE) const {
if (!BTNullRefArg)
BTNullRefArg.reset(new BuiltinBug(this, "Dereference of null pointer"));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r372363 - [NFCI] Always initialize const members of AttributeCommonInfo
Author: xiaobai
Date: Thu Sep 19 17:16:32 2019
New Revision: 372363
URL: http://llvm.org/viewvc/llvm-project?rev=372363&view=rev
Log:
[NFCI] Always initialize const members of AttributeCommonInfo
Some compilers require that const fields of an object must be explicitly
initialized by the constructor. I ran into this issue building with
clang 3.8 on Ubuntu 16.04.
Modified:
cfe/trunk/include/clang/Basic/AttributeCommonInfo.h
Modified: cfe/trunk/include/clang/Basic/AttributeCommonInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttributeCommonInfo.h?rev=372363&r1=372362&r2=372363&view=diff
==
--- cfe/trunk/include/clang/Basic/AttributeCommonInfo.h (original)
+++ cfe/trunk/include/clang/Basic/AttributeCommonInfo.h Thu Sep 19 17:16:32 2019
@@ -74,11 +74,11 @@ protected:
public:
AttributeCommonInfo(SourceRange AttrRange)
- : AttrRange(AttrRange), AttrKind(0), SyntaxUsed(0),
+ : AttrRange(AttrRange), ScopeLoc(), AttrKind(0), SyntaxUsed(0),
SpellingIndex(SpellingNotCalculated) {}
AttributeCommonInfo(SourceLocation AttrLoc)
- : AttrRange(AttrLoc), AttrKind(0), SyntaxUsed(0),
+ : AttrRange(AttrLoc), ScopeLoc(), AttrKind(0), SyntaxUsed(0),
SpellingIndex(SpellingNotCalculated) {}
AttributeCommonInfo(const IdentifierInfo *AttrName,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r368950 - [NFCI] Always initialize BugReport const fields
Author: xiaobai
Date: Wed Aug 14 17:58:51 2019
New Revision: 368950
URL: http://llvm.org/viewvc/llvm-project?rev=368950&view=rev
Log:
[NFCI] Always initialize BugReport const fields
Summary:
Some compilers require that const fields of an object must be explicitly
initialized by the constructor. I ran into this issue building with clang
3.8 on Ubuntu 16.04.
Reviewers: compnerd, Szelethus, NoQ
Subscribers: cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66265
Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h?rev=368950&r1=368949&r2=368950&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
(original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h Wed
Aug 14 17:58:51 2019
@@ -180,10 +180,12 @@ public:
/// to the user. This method allows to rest the location which should be used
/// for uniquing reports. For example, memory leaks checker, could set this
to
/// the allocation site, rather then the location where the bug is reported.
- BugReport(BugType& bt, StringRef desc, const ExplodedNode *errornode,
+ BugReport(BugType &bt, StringRef desc, const ExplodedNode *errornode,
PathDiagnosticLocation LocationToUnique, const Decl *DeclToUnique)
: BT(bt), Description(desc), UniqueingLocation(LocationToUnique),
-UniqueingDecl(DeclToUnique), ErrorNode(errornode) {}
+UniqueingDecl(DeclToUnique), ErrorNode(errornode),
+ErrorNodeRange(getStmt() ? getStmt()->getSourceRange()
+ : SourceRange()) {}
virtual ~BugReport() = default;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r368779 - [analyzer] Don't delete TaintConfig copy constructor
Author: xiaobai Date: Tue Aug 13 18:09:07 2019 New Revision: 368779 URL: http://llvm.org/viewvc/llvm-project?rev=368779&view=rev Log: [analyzer] Don't delete TaintConfig copy constructor Summary: Explicitly deleting the copy constructor makes compiling the function `ento::registerGenericTaintChecker` difficult with some compilers. When we construct an `llvm::Optional`, the optional is constructed with a const TaintConfig reference which it then uses to invoke the deleted TaintConfig copy constructor. I've observered this failing with clang 3.8 on Ubuntu 16.04. Reviewers: compnerd, Szelethus, boga95, NoQ, alexshap Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, llvm-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66192 Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp?rev=368779&r1=368778&r2=368779&view=diff == --- cfe/trunk/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp (original) +++ cfe/trunk/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp Tue Aug 13 18:09:07 2019 @@ -71,9 +71,9 @@ public: std::vector Sinks; TaintConfiguration() = default; -TaintConfiguration(const TaintConfiguration &) = delete; +TaintConfiguration(const TaintConfiguration &) = default; TaintConfiguration(TaintConfiguration &&) = default; -TaintConfiguration &operator=(const TaintConfiguration &) = delete; +TaintConfiguration &operator=(const TaintConfiguration &) = default; TaintConfiguration &operator=(TaintConfiguration &&) = default; }; ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
