[cfe-dev] Trouble understand DeclContext

[David Fontaine via cfe-dev]

I have some thoughts on this proposal, but rather than nitpick it 
inline, I think the issues would probably be better left to a code 
review.  The primary concern about my proposal seems to be "it may be 
risky or infeasible to patch everything else to handle this change," 
which could be made more concrete by me attempting to actually do it.  
Let me know if I'm misunderstanding.  For now, I have a working 
prototype, but it has some ugly workarounds.  I want to see if I can fix 
them properly without being too invasive, and how confident I am in the 
result.

Purely from a semantic perspective, hanging ParmVarDecls off of a 
VarDecl or FieldDecl seems the correct solution for function pointer 
parameters.  Going through the type information and the redeclaration 
chain seems highly unfortunate even if it might be less code motion.

Thanks,
-David


On 02/06/2017 10:20 PM, Serge Pavlov wrote:
> 2017-02-07 9:41 GMT+07:00 David Fontaine <dfontaine at nvidia.com 
> <mailto: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
>


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170207/de0dc439/attachment.html>