Dimb-dirdeclor
Disambiguate a direct declarator.
- Signature
(dimb-dirdeclor dirdeclor fundef-params-p table)
→
(mv erp new-dirdeclor new-fundef-params-p ident new-table)
- Arguments
- dirdeclor — Guard (dirdeclorp dirdeclor).
- fundef-params-p — Guard (booleanp fundef-params-p).
- table — Guard (dimb-tablep table).
- Returns
- new-dirdeclor — Type (dirdeclorp new-dirdeclor).
- new-fundef-params-p — Type (booleanp new-fundef-params-p).
- ident — Type (identp ident).
- new-table — Type (dimb-tablep new-table).
As explained in dimb-declor,
a (direct) declarator adds an identifier to the scope.
So here we return the identifer,
recursively extracted from the direct declarator.
The actual addition to the disambiguation table
is performed outside this function.
The meaning of the fundef-params-p flag passed as input is
the same as in dimb-declor: see that function's documentation.
We recursively disambiguate the inner declarator and direct declarator,
from which we obtain the identifier.
We also recursively disambiguate any expressions in array declarators.
For function declarators,
the parser only produces :function-params,
never :function-names.
However, here we also process :function-names,
so that the disambiguator is idempotent.
We push a new scope, for uniformity with the treatment
described in the next paragraph.
For a :function-params,
first we attempt to turn it into a :function-names, if applicable.
We pass fundef-params-p as the fundefp flag
to dimb-params-to-names,
which indicates whether the parameters in question
are for a function definition or not.
If this flag is t,
we push a new scope for the function parameters and body,
but it will be the declarations between the parameter names and the body
that will populate the newly pushed scope.
If this flag is nil,
we do not push a new scope,
because it just means that the list of parameters is empty,
but they are not the parameters of a function definition;
it is just a function prototype with no parameters.
If we cannot turn the :function-params into a :function-names,
we push a new scope for the parameters,
and we disambiguate the parameters (which adds them to the new scope),
passing the fundef-params-p resulting from
the recursive validation of the enclosed direct declarator.
This resulting flag is t if
the parameters of the function being defined
have not been disambiguated yet,
which means that the parameters of the current direct declarator
are in fact the ones of the function.
So we return nil as the new-fundef-params-p result,
so that any outer function declarator
is not treated as the one
whose parameters are for the function definition,
if we are validating one.
See the example in valid-dirdeclor for clarification;
validation and disambiguation follow the same pattern.
In any case, when the current function declarator
is the one whose parameters are for the function definition,
i.e. when fundef-params-p is t,
after disambiguating the parameters, which pushes a new scope with them,
we return the validation table as such,
so that when we later disambiguate the function body,
we already have the top-level scope for the body.
If instead fundef-params-p is nil,
the parameters form a function prototype scope [C17:6.2.1/4],
which is therefore popped.
