[clang] [clang][NFC] Refactor `Selector` to use `PointerIntPair` inside (PR #69916)
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Tue Oct 24 06:54:24 PDT 2023
================
@@ -809,43 +927,42 @@ class Selector {
enum IdentifierInfoFlag {
// Empty selector = 0. Note that these enumeration values must
// correspond to the enumeration values of DeclarationName::StoredNameKind
- ZeroArg = 0x01,
- OneArg = 0x02,
+ ZeroArg = 0x01,
+ OneArg = 0x02,
MultiArg = 0x07,
- ArgFlags = 0x07
};
/// A pointer to the MultiKeywordSelector or IdentifierInfo. We use the low
- /// three bits of InfoPtr to store an IdentifierInfoFlag. Note that in any
+ /// three bits of InfoPtr to store an IdentifierInfoFlag, but the highest
+ /// of them is also a discriminator for pointer type. Note that in any
/// case IdentifierInfo and MultiKeywordSelector are already aligned to
/// 8 bytes even on 32 bits archs because of DeclarationName.
- uintptr_t InfoPtr = 0;
+ llvm::PointerIntPair<
+ llvm::PointerUnion<IdentifierInfo *, MultiKeywordSelector *>, 2>
+ InfoPtr;
----------------
AaronBallman wrote:
```suggestion
llvm::PointerIntPair<
/// IMPORTANT NOTE: the order of the types in this PointerUnion are
/// important! The DeclarationName class has bidirectional conversion
/// to/from Selector through an opaque pointer (void *) which corresponds
/// to this PointerIntPair. The discriminator bit from the PointerUnion
/// corresponds to the high bit in the MultiArg enumerator. So while this
/// PointerIntPair only has two bits for the integer (and we mask off the
/// high bit in `MultiArg` when it is used), that discrimator bit is
/// still necessary for the opaque conversion. Do not reorder or add any
/// arguments to this template without thoroughly understanding how
/// tightly coupled these classes are.
llvm::PointerUnion<IdentifierInfo *, MultiKeywordSelector *>, 2>
InfoPtr;
```
https://github.com/llvm/llvm-project/pull/69916
More information about the cfe-commits
mailing list