[Lex] Expose a ModuleMacro's IdentifierInfo. #93
Conversation
…failures." This reverts commit d1cd5fd.
Usually the caller already has this information, but not always.
| @@ -515,6 +510,9 @@ class ModuleMacro : public llvm::FoldingSetNode { | |||
| ID.AddPointer(II); | |||
| } | |||
|
|
|||
| /// Get the name of the macro. | |||
| IdentifierInfo *getName() const { return II; } | |||
There was a problem hiding this comment.
@zygoloid, I'll bring this to Clang proper if it makes sense, but does it make sense? It seems like if we have this information it should be reasonable to ask for it, but if not I'll figure out another way to refer to "this particular macro definition by this name" in our lookup table. (Which doesn't have to keep pointer-sized entries, but it'd be nice if it could.)
There was a problem hiding this comment.
Yes, it seems fine to expose this; the name is part of the module macro abstraction and not just an implementation detail. I'm a little surprised we don't provide such an accessor already :)
|
The Swift WIP PR was merged, so I'm going to merge this one as well so that we can make progress on other issues. At least on the Swift side, there is more work to be done on this, though. |
Swift would like to be able to access the name of a ModuleMacro. There was some discussion of this in apple/swift-clang#93, suggesting that it makes sense to have this accessor in Clang. git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@310622 91177308-0d34-0410-b5e6-96231b3b80d8
Swift would like to be able to access the name of a ModuleMacro. There was some discussion of this in apple/swift-clang#93, suggesting that it makes sense to have this accessor in Clang. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310622 91177308-0d34-0410-b5e6-96231b3b80d8
Support for apple/swift#10519.