Add macro methods for lib-related nodes #14218
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves part of #3274. Resolves #5244.
This covers
LibDef
,CStructOrUnionDef
,FunDef
,TypeDef
, andExternalVar
. Most of those methods should be pretty straightforward, but some warrant a special mention:FunDef#real_name
,ExternalVar#real_name
: These return aStringLiteral
rather than aMacroId
to minimize the chances that the caller forgets#stringify
and produces invalid code. There is no way to distinguish between a node without a real name and a node whose real name is equal to its Crystal name, especially sinceCrystal::FunDef#real_name
is not nilable.FunDef#body
,#has_body?
: The former may return aNop
for both lib funs and top-level funs, so the latter is necessary.CStructOrUnionDef#name
,TypeDef#name
: These return aPath
rather than aMacroId
to resemble AST nodes outside libs, even though syntactically they cannot be anything other than a single constant.