[cfe-dev] ParamDecls missing from function DeclContext

[Douglas Gregor]

On May 15, 2012, at 8:04 AM, Abramo Bagnara <abramo.bagnara at gmail.com> wrote:

> Il 15/05/2012 16:36, Douglas Gregor ha scritto:
>> 
>> On May 15, 2012, at 12:40 AM, Abramo Bagnara wrote:
>> 
>>> Another much related issue is shown by the following:
>>> 
>>> void sort(int (*compare)(int x, int y), int* x);
>>> 
>>> Which should be the correct context of ParmVarDecl's inside
>>> FunctionType (i.e. int x and int y)?
>> 
>> 
>> The DeclContext notion breaks down a little bit here, because we 
>> don't create a context for FunctionTypes (and shouldn't). I'd rather
>> that the inner ParmVarDecls be in the 'sort's FunctionDecl.
> 
> Also if I don't have any problem with this I'd like to understand why
> you think that FunctionTypeLoc should not have a pointer to a
> DeclContext where the args are registered (that for FunctionDecl
> function type is the very same FunctionDecl).

I'd rather not spend any storage on a DeclContext* in the FunctionTypeLoc.

> Apart this issue we have added to our AST visitors an experimental
> assertion to verify that if the DeclContext for declaration D is DC,
> then the DeclContext DC indeed contains declaration D.
> 
> We get tons of assertion failures (e.g. for FunctionDecl or
> CXXRecordDecl inside a template declaration).
> 
> We'd like to understand if this is unexpected (and in general we should
> always have that if D points to DC then DC should contains D) or if we
> are equivocating the overall design of DeclContext's.


For non-function, non-block DeclContext, this is an important invariant.

For function and block contexts, it doesn't matter: all of the declarations will be reachable via other means, because they are part of the declaration or one of the statements in the definition. If we're to do any work in the area of DeclContext for functions and blocks, I would much rather make them simpler---by eliminating both the lookup tables and the list of lexical declarations---and save the storage, rather than making them meet an invariant that doesn't seem to have any benefits.

	- Doug