Skip to content
This repository has been archived by the owner on Mar 28, 2020. It is now read-only.

[Lex] Expose a ModuleMacro's IdentifierInfo. #93

Merged
merged 2 commits into from
Jul 5, 2017
Merged

[Lex] Expose a ModuleMacro's IdentifierInfo. #93

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b1404c0
Revert "Temporary hack to allow making progress on master-next build …
jrose-apple Jun 15, 2017
3f87783
[Lex] Expose a ModuleMacro's IdentifierInfo.
jrose-apple Jun 19, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 3 additions & 5 deletions include/clang/Lex/MacroInfo.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -266,11 +266,6 @@ class MacroInfo {

void setUsedForHeaderGuard(bool Val) { UsedForHeaderGuard = Val; }

// FIXME: hack to get past build failures
unsigned getOwningModuleID() const {
return 0;
}

void dump() const;

private:
Expand Down Expand Up @@ -515,6 +510,9 @@ class ModuleMacro : public llvm::FoldingSetNode {
ID.AddPointer(II);
}

/// Get the name of the macro.
IdentifierInfo *getName() const { return II; }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)


/// Get the ID of the module that exports this macro.
Module *getOwningModule() const { return OwningModule; }

Expand Down