aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CGObjCMac.cpp
AgeCommit message (Collapse)AuthorFilesLines
3 days[clang] NFC: rename TagType::getOriginalDecl back to getDecl (#163271)Matheus Izvekov1-2/+2
This rename was made as part of https://github.com/llvm/llvm-project/pull/147835 in order to ease rebasing the PR, and give a nice window for other patches to get rebased as well. It has been a while already, so lets go ahead and rename it back.
2025-10-01[AST] Give `CharUnits::operator%` a consistent type. NFC (#160781)Justin Bogner1-1/+1
Update the `operator%` overload that accepts `CharUnits` to return `CharUnits` to match the other `operator%`. This is more logical than returning an `int64` and cleans up users that want to continue to do math with the result. Many users of this were explicitly comparing against 0. I considered updating these to compare against `CharUnits::Zero` or even introducing an `explicit operator bool()`, but they all feel clearer if we update them to use the existing `isMultipleOf()` function instead.
2025-08-27[clang] AST: fix getAs canonicalization of leaf types (#155028)Matheus Izvekov1-6/+6
2025-08-25[clang] NFC: change more places to use Type::getAsTagDecl and friends (#155313)Matheus Izvekov1-3/+2
This changes a bunch of places which use getAs<TagType>, including derived types, just to obtain the tag definition. This is preparation for #155028, offloading all the changes that PR used to introduce which don't depend on any new helpers.
2025-08-09[clang] Improve nested name specifier AST representation (#147835)Matheus Izvekov1-5/+6
This is a major change on how we represent nested name qualifications in the AST. * The nested name specifier itself and how it's stored is changed. The prefixes for types are handled within the type hierarchy, which makes canonicalization for them super cheap, no memory allocation required. Also translating a type into nested name specifier form becomes a no-op. An identifier is stored as a DependentNameType. The nested name specifier gains a lightweight handle class, to be used instead of passing around pointers, which is similar to what is implemented for TemplateName. There is still one free bit available, and this handle can be used within a PointerUnion and PointerIntPair, which should keep bit-packing aficionados happy. * The ElaboratedType node is removed, all type nodes in which it could previously apply to can now store the elaborated keyword and name qualifier, tail allocating when present. * TagTypes can now point to the exact declaration found when producing these, as opposed to the previous situation of there only existing one TagType per entity. This increases the amount of type sugar retained, and can have several applications, for example in tracking module ownership, and other tools which care about source file origins, such as IWYU. These TagTypes are lazily allocated, in order to limit the increase in AST size. This patch offers a great performance benefit. It greatly improves compilation time for [stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for `test_on2.cpp` in that project, which is the slowest compiling test, this patch improves `-c` compilation time by about 7.2%, with the `-fsyntax-only` improvement being at ~12%. This has great results on compile-time-tracker as well: ![image](https://github.com/user-attachments/assets/700dce98-2cab-4aa8-97d1-b038c0bee831) This patch also further enables other optimziations in the future, and will reduce the performance impact of template specialization resugaring when that lands. It has some other miscelaneous drive-by fixes. About the review: Yes the patch is huge, sorry about that. Part of the reason is that I started by the nested name specifier part, before the ElaboratedType part, but that had a huge performance downside, as ElaboratedType is a big performance hog. I didn't have the steam to go back and change the patch after the fact. There is also a lot of internal API changes, and it made sense to remove ElaboratedType in one go, versus removing it from one type at a time, as that would present much more churn to the users. Also, the nested name specifier having a different API avoids missing changes related to how prefixes work now, which could make existing code compile but not work. How to review: The important changes are all in `clang/include/clang/AST` and `clang/lib/AST`, with also important changes in `clang/lib/Sema/TreeTransform.h`. The rest and bulk of the changes are mostly consequences of the changes in API. PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just for easier to rebasing. I plan to rename it back after this lands. Fixes #136624 Fixes https://github.com/llvm/llvm-project/issues/43179 Fixes https://github.com/llvm/llvm-project/issues/68670 Fixes https://github.com/llvm/llvm-project/issues/92757
2025-07-19Reland [Clang] Make the SizeType, SignedSizeType and PtrdiffType be named ↵YexuanXiao1-1/+1
sugar types (#149613) The checks for the 'z' and 't' format specifiers added in the original PR #143653 had some issues and were overly strict, causing some build failures and were consequently reverted at https://github.com/llvm/llvm-project/commit/4c85bf2fe8042c855c9dd5be4b02191e9d071ffd. In the latest commit https://github.com/llvm/llvm-project/pull/149613/commits/27c58629ec76a703fde9c0b99b170573170b4a7a, I relaxed the checks for the 'z' and 't' format specifiers, so warnings are now only issued when they are used with mismatched types. The original intent of these checks was to diagnose code that assumes the underlying type of `size_t` is `unsigned` or `unsigned long`, for example: ```c printf("%zu", 1ul); // Not portable, but not an error when size_t is unsigned long ``` However, it produced a significant number of false positives. This was partly because Clang does not treat the `typedef` `size_t` and `__size_t` as having a common "sugar" type, and partly because a large amount of existing code either assumes `unsigned` (or `unsigned long`) is `size_t`, or they define the equivalent of size_t in their own way (such as sanitizer_internal_defs.h).https://github.com/llvm/llvm-project/blob/2e67dcfdcd023df2f06e0823eeea23990ce41534/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h#L203
2025-07-17Revert "[Clang] Make the SizeType, SignedSizeType and PtrdiffType be named ↵Kazu Hirata1-1/+1
sugar types instead of built-in types (#143653)" This reverts commit c27e283cfbca2bd22f34592430e98ee76ed60ad8. A builbot failure has been reported: https://lab.llvm.org/buildbot/#/builders/186/builds/10819/steps/10/logs/stdio I'm also getting a large number of warnings related to %zu and %zx.
2025-07-17[Clang] Make the SizeType, SignedSizeType and PtrdiffType be named sugar ↵YexuanXiao1-1/+1
types instead of built-in types (#143653) Including the results of `sizeof`, `sizeof...`, `__datasizeof`, `__alignof`, `_Alignof`, `alignof`, `_Countof`, `size_t` literals, and signed `size_t` literals, the results of pointer-pointer subtraction and checks for standard library functions (and their calls). The goal is to enable clang and downstream tools such as clangd and clang-tidy to provide more portable hints and diagnostics. The previous discussion can be found at #136542. This PR implements this feature by introducing a new subtype of `Type` called `PredefinedSugarType`, which was considered appropriate in discussions. I tried to keep `PredefinedSugarType` simple enough yet not limited to `size_t` and `ptrdiff_t` so that it can be used for other purposes. `PredefinedSugarType` wraps a canonical `Type` and provides a name, conceptually similar to a compiler internal `TypedefType` but without depending on a `TypedefDecl` or a source file. Additionally, checks for the `z` and `t` format specifiers in format strings for `scanf` and `printf` were added. It will precisely match expressions using `typedef`s or built-in expressions. The affected tests indicates that it works very well. Several code require that `SizeType` is canonical, so I kept `SizeType` to its canonical form. The failed tests in CI are allowed to fail. See the [comment](https://github.com/llvm/llvm-project/pull/135386#issuecomment-3049426611) in another PR #135386.
2025-07-14[clang][ObjC][PAC] Add ptrauth protections to objective-c (#147899)Oliver Hunt1-24/+70
This PR introduces the use of pointer authentication to objective-c[++]. This includes: * __ptrauth qualifier support for ivars * protection of isa and super fields * protection of SEL typed ivars * protection of class_ro_t data * protection of methodlist pointers and content
2025-06-19[CodeGen] Use range-based for loops (NFC) (#144939)Kazu Hirata1-12/+8
2025-04-19[clang] llvm::append_range (NFC) (#136440)Kazu Hirata1-1/+1
2025-04-05[clang][CGObjC] Remove unused ExternalProtocolPtrTy (NFC) (#133870)Mats Jun Larsen1-21/+1
This function was previously used to get a type to the protocol that was used to bitcast the initializer of GenerateProtocol. This bitcast has later been removed (thanks to opaque pointers), but the member was left behind. History: - 020de3254acc3 used ExternalProtocolPtrTy - 34ee69b4ce662 removes the bitcast Also technically part of #123569
2025-04-04[clang][CGObjC] Prefer PointerType::get with LLVMContext over Type (NFC) ↵Mats Jun Larsen1-28/+27
(#133871) Part of #123569
2025-03-04[ObjC] Expand isClassLayoutKnownStatically to base classes as long as the ↵AZero131-2/+5
implementation of it is known (#85465) Only NSObject we can trust the layout of won't change even though we cannot directly see its @implementation
2025-02-17[CodeGen][ObjC] Invalidate cached ObjC class layout information after ↵Akira Hatanaka1-3/+4
parsing ObjC class implementations if new ivars are added to the interface (#126591) The layout and the size of an ObjC interface can change after its corresponding implementation is parsed when synthesized ivars or ivars declared in categories are added to the interface's list of ivars. This can cause clang to mis-compile if the optimization that emits fixed offsets for ivars (see 923ddf65f4e21ec67018cf56e823895de18d83bc) uses an ObjC class layout that is outdated and no longer reflects the current state of the class. For example, when compiling `constant-non-fragile-ivar-offset.m`, clang emits 20 instead of 24 as the offset for `IntermediateClass2Property` as the class layout for `SuperClass2`, which is created when the implementation of IntermediateClass3 is parsed, is outdated when the implementation of `IntermediateClass2` is parsed. This commit invalidates the stale layout information of the class and its subclasses if new ivars are added to the interface. With this change, we can also stop using ObjC implementation decls as the key to retrieve ObjC class layouts information as the layout retrieved using the ObjC interface as the key will always be up to date. rdar://139531391
2025-02-12[clang] run clang-format on some CGObjC files (#126644)Peter Rong1-1169/+1043
These files are relatively old and don't confront our formatting rules. It's hard to change them without massive clang-format changes. --------- Signed-off-by: Peter Rong <PeterRong@meta.com>
2025-02-08[CodeGen] Replace of PointerType::get(Type) with opaque version (NFC) (#124771)Mats Jun Larsen1-1/+1
Follow-up to https://github.com/llvm/llvm-project/issues/123569
2025-01-11Reapply "[clang] Avoid re-evaluating field bitwidth" (#122289)Timm Baeder1-2/+1
2025-01-08Revert "[clang] Avoid re-evaluating field bitwidth (#117732)"Timm Bäder1-1/+2
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54. This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp: lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
2025-01-08[clang] Avoid re-evaluating field bitwidth (#117732)Timm Baeder1-2/+1
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply returns the value from the `ConstantExpr` instead of constant-evaluating the bitwidth expression every time it is called.
2024-11-16[CodeGen] Remove unused includes (NFC) (#116459)Kazu Hirata1-2/+0
Identified with misc-include-cleaner.
2024-11-05Remove leftover uses of llvm::Type::getPointerTo() (#114993)Youngsuk Kim1-16/+12
`llvm::Type::getPointerTo()` is to be deprecated. Replace remaining uses of it.
2024-10-30[clang] Remove some uses of llvm::StructType::setBody. NFC. (#113691)Jay Foad1-30/+27
It is simple to create the struct body up front, now that we have transitioned to opaque pointers.
2024-10-24[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399)Jay Foad1-2/+2
Follow up to #109133.
2024-06-24Revert "[IR][NFC] Update IRBuilder to use InsertPosition (#96497)"Stephen Tozer1-1/+1
Reverts the above commit, as it updates a common header function and did not update all callsites: https://lab.llvm.org/buildbot/#/builders/29/builds/382 This reverts commit 6481dc57612671ebe77fe9c34214fba94e1b3b27.
2024-06-24[IR][NFC] Update IRBuilder to use InsertPosition (#96497)Stephen Tozer1-1/+1
Uses the new InsertPosition class (added in #94226) to simplify some of the IRBuilder interface, and removes the need to pass a BasicBlock alongside a BasicBlock::iterator, using the fact that we can now get the parent basic block from the iterator even if it points to the sentinel. This patch removes the BasicBlock argument from each constructor or call to setInsertPoint. This has no functional effect, but later on as we look to remove the `Instruction *InsertBefore` argument from instruction-creation (discussed [here](https://discourse.llvm.org/t/psa-instruction-constructors-changing-to-iterator-only-insertion/77845)), this will simplify the process by allowing us to deprecate the InsertPosition constructor directly and catch all the cases where we use instructions rather than iterators.
2024-06-10[NFCI][metadata][clang] Use create{Unlikely,Likely}BranchWeights (#89467)Vitaly Buka1-1/+1
It does not look like particular value is inportant. Howere, there is a comment., but the current implementation of `create{Unlikely,Likely}BranchWeights` use the same value. Follow up to #89464
2024-04-11[NFC][Clang] Improve const correctness for IdentifierInfo (#79365)Bill Wendling1-7/+6
The IdentifierInfo isn't typically modified. Use 'const' wherever possible.
2024-03-28[CodeGen][arm64e] Add methods and data members to Address, which are needed ↵Akira Hatanaka1-47/+48
to authenticate signed pointers (#86923) To authenticate pointers, CodeGen needs access to the key and discriminators that were used to sign the pointer. That information is sometimes known from the context, but not always, which is why `Address` needs to hold that information. This patch adds methods and data members to `Address`, which will be needed in subsequent patches to authenticate signed pointers, and uses the newly added methods throughout CodeGen. Although this patch isn't strictly NFC as it causes CodeGen to use different code paths in some cases (e.g., `mergeAddressesInConditionalExpr`), it doesn't cause any changes in functionality as it doesn't add any information needed for authentication. In addition to the changes mentioned above, this patch introduces class `RawAddress`, which contains a pointer that we know is unsigned, and adds several new functions for creating `Address` and `LValue` objects. This reapplies d9a685a9dd589486e882b722e513ee7b8c84870c, which was reverted because it broke ubsan bots. There seems to be a bug in coroutine code-gen, which is causing EmitTypeCheck to use the wrong alignment. For now, pass alignment zero to EmitTypeCheck so that it can compute the correct alignment based on the passed type (see function EmitCXXMemberOrOperatorMemberCallExpr).
2024-03-27Revert "[CodeGen][arm64e] Add methods and data members to Address, which are ↵Akira Hatanaka1-48/+47
needed to authenticate signed pointers (#86721)" (#86898) This reverts commit d9a685a9dd589486e882b722e513ee7b8c84870c. The commit broke ubsan bots.
2024-03-27[CodeGen][arm64e] Add methods and data members to Address, which are needed ↵Akira Hatanaka1-47/+48
to authenticate signed pointers (#86721) To authenticate pointers, CodeGen needs access to the key and discriminators that were used to sign the pointer. That information is sometimes known from the context, but not always, which is why `Address` needs to hold that information. This patch adds methods and data members to `Address`, which will be needed in subsequent patches to authenticate signed pointers, and uses the newly added methods throughout CodeGen. Although this patch isn't strictly NFC as it causes CodeGen to use different code paths in some cases (e.g., `mergeAddressesInConditionalExpr`), it doesn't cause any changes in functionality as it doesn't add any information needed for authentication. In addition to the changes mentioned above, this patch introduces class `RawAddress`, which contains a pointer that we know is unsigned, and adds several new functions for creating `Address` and `LValue` objects. This reapplies 8bd1f9116aab879183f34707e6d21c7051d083b6. The commit broke msan bots because LValue::IsKnownNonNull was uninitialized.
2024-03-26[NFC] Refactor ConstantArrayType size storage (#85716)Chris B1-3/+3
In PR #79382, I need to add a new type that derives from ConstantArrayType. This means that ConstantArrayType can no longer use `llvm::TrailingObjects` to store the trailing optional Expr*. This change refactors ConstantArrayType to store a 60-bit integer and 4-bits for the integer size in bytes. This replaces the APInt field previously in the type but preserves enough information to recreate it where needed. To reduce the number of places where the APInt is re-constructed I've also added some helper methods to the ConstantArrayType to allow some common use cases that operate on either the stored small integer or the APInt as appropriate. Resolves #85124.
2024-03-26Revert "[CodeGen][arm64e] Add methods and data members to Address, which are ↵Akira Hatanaka1-48/+47
needed to authenticate signed pointers (#67454)" (#86674) This reverts commit 8bd1f9116aab879183f34707e6d21c7051d083b6. It appears that the commit broke msan bots.
2024-03-25[CodeGen][arm64e] Add methods and data members to Address, which are needed ↵Akira Hatanaka1-47/+48
to authenticate signed pointers (#67454) To authenticate pointers, CodeGen needs access to the key and discriminators that were used to sign the pointer. That information is sometimes known from the context, but not always, which is why `Address` needs to hold that information. This patch adds methods and data members to `Address`, which will be needed in subsequent patches to authenticate signed pointers, and uses the newly added methods throughout CodeGen. Although this patch isn't strictly NFC as it causes CodeGen to use different code paths in some cases (e.g., `mergeAddressesInConditionalExpr`), it doesn't cause any changes in functionality as it doesn't add any information needed for authentication. In addition to the changes mentioned above, this patch introduces class `RawAddress`, which contains a pointer that we know is unsigned, and adds several new functions for creating `Address` and `LValue` objects.
2024-03-05[ObjC] Check entire chain of superclasses to see if class layout is ↵AtariDreams1-6/+14
statically known (#81335) As of now, we only check if a class directly inherits from NSObject to determine if said class has fixed offsets and can therefore "opt-out" from the non-fragile ABI for ivars. However, if an NSObject subclass has fixed offsets, then so must the subclasses of that subclass, so this allows us to optimize instances of subclasses of subclasses that inherit from NSObject and so on. To determine this, we need to find that the compiler can see the implementation of each intermediate class, as that means it is statically linked. Fixes: #81369
2024-01-31[clang] Use StringRef::starts_with (NFC)Kazu Hirata1-4/+2
2023-12-13[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)Kazu Hirata1-2/+2
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-11-18[CGObjCMac] Replace calls to ConstantAggregateBuilderBase::addBitCast (NFC)Youngsuk Kim1-17/+11
Replace calls to `ConstantAggregateBuilderBase::addBitCast` that involve a no-op ptr-to-ptr bitcast. Opaque ptr cleanup effort (NFC)
2023-11-06[clang][CGObjCMac] Remove no-op ptr-to-ptr bitcasts (NFC)Youngsuk Kim1-39/+23
Opaque ptr cleanup effort (NFC).
2023-11-03[clang][NFC] Refactor `TagTypeKind` (#71160)Vlad Serebrennikov1-8/+6
This patch converts TagTypeKind into scoped enum. Among other benefits, this allows us to forward-declare it where necessary.
2023-09-30[clang] Remove uses of llvm::Type::getPointerTo() (NFC)JOE19941-14/+6
* Remove if its sole use is to support an unnecessary ptr-to-ptr bitcast (remove the bitcast as well) * Replace with use of other APIs. NFC opaque pointer cleanup effort.
2023-08-20[CodeGen] Modernize NullReturnState (NFC)Kazu Hirata1-2/+2
2023-07-28Remove private rdar links. NFCAkira Hatanaka1-10/+7
Differential Revision: https://reviews.llvm.org/D156576
2023-07-17Revert "Remove rdar links; NFC"Mehdi Amini1-3/+4
This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d. This commit wasn't reviewed ahead of time and significant concerns were raised immediately after it landed. According to our developer policy this warrants immediate revert of the commit. https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy Differential Revision: https://reviews.llvm.org/D155509
2023-07-07Remove rdar links; NFCAaron Ballman1-4/+3
This removes links to rdar, which is an internal bug tracker that the community doesn't have visibility into. See further discussion at: https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847
2023-06-18[clang] Replace uses of CGBuilderTy::CreateElementBitCast (NFC)Youngsuk Kim1-10/+3
* Add `Address::withElementType()` as a replacement for `CGBuilderTy::CreateElementBitCast`. * Partial progress towards replacing `CreateElementBitCast`, as it no longer does what its name suggests. Either replace its uses with `Address::withElementType()`, or remove them if no longer needed. * Remove unused parameter 'Name' of `CreateElementBitCast` Reviewed By: barannikov88, nikic Differential Revision: https://reviews.llvm.org/D153196
2023-06-13Remove dead conditionalsSindhu Chittireddy1-9/+3
2023-06-11[CodeGen] Use DenseMapBase::lookup (NFC)Kazu Hirata1-6/+1
2023-06-02[CodeGen] Use llvm::LLVMContext::MD_invariant_load (NFC)Kazu Hirata1-2/+2
2023-02-14Recommit: [NFC][IR] Make Module::getGlobalList() privateVasileios Porpodas1-1/+1
This reverts commit cb5f239363a3c94db5425c105fcd45e77d2a16a9.