[clang] de27291 - Add missing header guards so the modules build will succeed.

[Jim Ingham via cfe-commits]

Author: Jim Ingham
Date: 2023-04-19T17:24:11-07:00
New Revision: de27291e25f7398b0b36c0f388eaf272b2b54e37

URL: 
https://github.com/llvm/llvm-project/commit/de27291e25f7398b0b36c0f388eaf272b2b54e37
DIFF: 
https://github.com/llvm/llvm-project/commit/de27291e25f7398b0b36c0f388eaf272b2b54e37.diff

LOG: Add missing header guards so the modules build will succeed.

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/Arena.h

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/Arena.h 
b/clang/include/clang/Analysis/FlowSensitive/Arena.h
index 8dc51e044b14f..d8a123c52eb83 100644
--- a/clang/include/clang/Analysis/FlowSensitive/Arena.h
+++ b/clang/include/clang/Analysis/FlowSensitive/Arena.h
@@ -5,6 +5,8 @@
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE__ARENA_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE__ARENA_H
 
 #include "clang/Analysis/FlowSensitive/StorageLocation.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
@@ -118,3 +120,5 @@ class Arena {
 };
 
 } // namespace clang::dataflow
+
+#endif // LLVM_CLANG_ANALYSIS_FLOWSENSITIVE__ARENA_H



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [Lldb-commits] [PATCH] D78807: Fix gendered documentation

[Jim Ingham via cfe-commits]

A lot of our comments and documentation was written a while ago when the “good” 
practice was to be careful to use “he” and “she” in equal measure when 
referring to our users.  The consensus has shifted to using “they” instead, so 
there are probably a bunch of other places using he and she.  Please feel free 
to fix this wherever you see it!

Thanks!

Jim

> On Apr 24, 2020, at 9:43 AM, Jonas Devlieghere via Phabricator via 
> lldb-commits  wrote:
> 
> JDevlieghere accepted this revision.
> JDevlieghere added a comment.
> 
> Thank you!
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D78807/new/
> 
> https://reviews.llvm.org/D78807
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D53547: NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

[Jim Ingham via cfe-commits]

> On Oct 23, 2018, at 11:09 AM, Erik Pilkington via Phabricator 
>  wrote:
> 
> erik.pilkington added a subscriber: jingham.
> erik.pilkington added inline comments.
> 
> 
> 
> Comment at: clang/lib/Basic/IdentifierTable.cpp:166-167
>   // in non-arc mode.
> -  if (LangOpts.ObjC2 && (Flags & KEYARC)) return KS_Enabled;
> -  if (LangOpts.ObjC2 && (Flags & KEYOBJC2)) return KS_Enabled;
> +  if (LangOpts.ObjC && (Flags & KEYARC)) return KS_Enabled;
> +  if (LangOpts.ObjC && (Flags & KEYOBJC)) return KS_Enabled;
>   if (LangOpts.ConceptsTS && (Flags & KEYCONCEPTS)) return KS_Enabled;
> 
> rsmith wrote:
>> Would it make sense to fold `KEYOBJC` and `KEYARC` together?
> Yep, good point. Looks like we used to only enable these keywords in 
> -fobjc-arc mode, but now that we're doing it for objective-c there isn't any 
> distinction to be made here. I'll commit this in a follow-up.
> 
> 
> 
> Comment at: 
> lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:408
> // non-Apple platforms, but for now it is needed.
> -m_compiler->getLangOpts().ObjC1 = true;
> +m_compiler->getLangOpts().ObjC = true;
> break;
> 
> rsmith wrote:
>> Curious, this looks like it was the *only* way we previously ever got into 
>> `ObjC1` mode. Any idea why this path turns on `ObjC1` but not `ObjC2`?
> This comes from https://reviews.llvm.org/D11102. I can't really imagine this 
> being anything but an oversight, I doubt that there is some subtle reason to 
> use ObjC1. @jingham: Can you confirm that there isn't any reason to use just 
> ObjC1 and not ObjC1+ObjC2 here?

This certainly does seem like an oversight, and I can't think of any good 
reason why this change just set ObjC1 and not ObjC2 like all the other places 
this was done.

Jim


> 
> 
> https://reviews.llvm.org/D53547
> 
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits