[cfe-dev] Trouble understand DeclContext

Serge Pavlov via cfe-dev cfe-dev at lists.llvm.org
Mon Feb 6 22:20:57 PST 2017


2017-02-07 9:41 GMT+07:00 David Fontaine <dfontaine at nvidia.com>:

> "The DeclContext is a declaration that is a container for other
> declarations. All non-leaf nodes of AST inherit it. If a contained
> declaration itself can contain other declarations (nested class, method of
> a class etc), it will be a nested DeclContext."
>
>
> Based on this, it seems that VarDecl and FieldDecl should also inherit
> DeclContext, because a function pointer declaration, which may contain
> named parameters, would be one of those two.  Any opinion on this?
>
Nor VarDecl neither FieldDecl contain other declarations, so making them
DeclContext is not obvious. DeclContext is used in many places including
name lookup and such drastic semantic change can require redesign of other
compiler components. And what about such case:

int (* (*abc)(long x))(int x);

Two DeclContexts would be needed here.

I would propose you another way, which probably is less invasive. The
parameter names are not attributes of VarDecl, it looks more natural to
obtained from corresponding function type, which can be obtained:

VarDecl->getType()->getAs<PointerType>()->getPointeeType()->getAs<FunctionProtoType>()

If FunctionProtoType had method `getDecl` as `RecordDecl` has, you could
get the parameter declarations from corresponding FunctionDecl. So you need
to construct bogus function declaration when parsing function pointer
declaration and attach it to the FunctionProtoType. There is however a
problem with different declarations for the same type:

void (*pFn)(int x);
void (*pFn2)(int y);

The variables have the same type, but to keep named parameters you need
different FunctionDecls. Probably the bogus declarations should be linked
into redeclaration chain.

It is only an idea, I don't know if it is viable.

Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170207/8c540483/attachment.html>


More information about the cfe-dev mailing list