<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 21, 2012, at 11:46 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, May 21, 2012 at 11:03 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On May 16, 2012, at 10:49 AM, Abramo Bagnara <<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a>> wrote:<br>
<br>
> Il 16/05/2012 17:57, Douglas Gregor ha scritto:<br>
>><br>
>>>><br>
</div><div><div class="h5">>>>>> That said, the invariant that the decls list on a DeclContext is<br>
>>>>> exactly the list of Decls which have that DC as their lexical context<br>
>>>>> would be useful. In particular, it could be useful for some clients to<br>
>>>>> guarantee that traversing Decls by recursively iterating all lexical<br>
>>>>> decls in all DCs would, in fact, reach all Decls.<br>
>>>><br>
>>>> Okay, I agree that this is a useful general invariant.<br>
>>><br>
>>> Everything is very nice in this way and we'd love to do in this way, but<br>
>>> this contrasts with<br>
>>><br>
>>>>> Abramo wrote:<br>
>>>>> Also if I don't have any problem with this I'd like to understand why<br>
>>>>> you think that FunctionTypeLoc should not have a pointer to a<br>
>>>>> DeclContext where the args are registered (that for FunctionDecl<br>
>>>>> function type is the very same FunctionDecl).<br>
>>><br>
>>>> Doug answer:<br>
>>>> I'd rather not spend any storage on a DeclContext* in the FunctionTypeLoc.<br>
>>><br>
>>> Suppose we have:<br>
>>> typedef int f(int x);<br>
>>><br>
>>> We should assign to int x a lexical DeclContext, suppose we choose to<br>
>>> assign it to the TranslationUnit... then to satisfy the invariant above<br>
>>> we should insert the ParmVarDecl in the TranslationUnit.<br>
>>><br>
>>> I really doubt this is sane choice... what happens to all visitors of<br>
>>> DeclContext when they encounter these ParmVarDecl (that I'd say are<br>
>>> definitely "misplaced"...)<br>
>><br>
>><br>
>> The C(++) languages don't actually place such declarations in any<br>
>> particular context, so it's not clear where they belong in the AST.<br>
>> Introducing some kind of abstract function declaration that is the<br>
>> DeclContext might conceivably work, but that's a rather heavyweight<br>
>> solution just to maintain an invariant. Using FunctionTypeLoc doesn't<br>
>> really work, because DeclContexts are supposed to be Decls.<br>
><br>
> Just to be clear, I was not thinking to transform FunctionTypeLoc in a<br>
> DeclContext, but to put a DeclContext* in FunctionTypeLoc data.<br>
><br>
> This pointer points to FunctionDecl itself when the FunctionTypeLoc is<br>
> the type of a FunctionDecl, otherwise it points to a specific class<br>
> derived from DeclContext (FunctionTypeDeclContext?) that contains only<br>
> the ParmVarDecl's.<br>
<br>
</div></div>In the FunctionDecl case, we don't actually need this pointer because it is available in the ParmVarDecls. Can we optimize it away?<br>
<div class="im"><br>
>> Personally, I'm fine with having parameters in the lexical<br>
>> DeclContext of the translation unit for this case, but we can investigate other designs.<br>
><br>
> How you would skip them?<br>
<br>
</div>isa<ParmVarDecl>?<br>
<div class="im"><br>
> What about template instantiation of these? Everything would be added to<br>
> TranslationUnit?<br>
<br>
</div>I guess so.<br>
<div class="im"><br>
> Perhaps I'm the only to feel this way, but to add Decls to contexts<br>
> where they don't belong sincerely appears like a little mess to me...<br>
<br>
</div>I agree that it feels a little messy, but we're discussing increasing Clang's memory footprint to meet an invariant that we've never needed before. Make it cheap or make it important and it becomes obvious that it's worth doing.<br>
</blockquote></div><br><div>It's not completely clear to me what invariant a FunctionTypeDeclContext would help with.</div>
</blockquote><br></div><div>I think the intent is that the FunctionTypeDeclContext be the context used for parameters in a function type that is *not* directly the type of a function or function template declaration. One could then iterate over the lexical declarations in the FunctionTypeDeclContext to get the ParmVarDecls in that function type.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br></div><br></body></html>