r368779 - [analyzer] Don't delete TaintConfig copy constructor

2019-08-14 Thread Alex Langford via cfe-commits 
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

r368950 - [NFCI] Always initialize BugReport const fields

2019-08-14 Thread Alex Langford via cfe-commits 
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

r372363 - [NFCI] Always initialize const members of AttributeCommonInfo

2019-09-19 Thread Alex Langford via cfe-commits 
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

r372668 - [NFCI] Return PathSensitiveBugReport where appropriate

2019-09-23 Thread Alex Langford via cfe-commits 
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

[clang] c57f034 - [clang][Sema] Add flag to LookupName to force C/ObjC codepath

2022-04-19 Thread Alex Langford via cfe-commits 

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] 266ec80 - [clang][DebugInfo] Respect fmodule-file-home-is-cwd in skeleton CUs for clang modules

2022-10-04 Thread Alex Langford via cfe-commits 

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] b3f789e - [perf-training] Change profile file pattern string to use %4m instead of %p

2019-12-17 Thread Alex Langford via cfe-commits 

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

[clang] [lldb] [llvm] [llvm][TargetParser] Return optional from getHostCPUFeatures (PR #97824)

2024-07-05 Thread Alex Langford via cfe-commits 

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] Use CLANG_RESOURCE_DIR more consistently (PR #103388)

2024-08-13 Thread Alex Langford via cfe-commits 

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] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3804: lacking () for c… (PR #90391)

2024-04-29 Thread Alex Langford via cfe-commits 

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] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)

2024-04-30 Thread Alex Langford via cfe-commits 

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] [lldb] [llvm] [llvm][TargetParser] Return StringMap from getHostCPUFeatures (PR #97824)

2024-07-09 Thread Alex Langford via cfe-commits 


@@ -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 StringMap from getHostCPUFeatures (PR #97824)

2024-07-10 Thread Alex Langford via cfe-commits 

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] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)

2024-05-13 Thread Alex Langford via cfe-commits 

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] [lldb] [llvm] [openmp] [polly] fix(python): fix comparison to True/False (PR #91858)

2024-05-14 Thread Alex Langford via cfe-commits 

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