Dimb-dirdeclor
Disambiguate a direct declarator.
- Signature
(dimb-dirdeclor dirdeclor fundefp table)
→
(mv erp new-dirdeclor ident new-table)
- Arguments
- dirdeclor — Guard (dirdeclorp dirdeclor).
- fundefp — Guard (booleanp fundefp).
- table — Guard (dimb-tablep table).
- Returns
- new-dirdeclor — Type (dirdeclorp new-dirdeclor).
- 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 purpose of the fundefp flag is
the same as in dimb-declor,
which in fact passes it to this function.
Here we make use of it, as explained below.
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 also push a new scope if fundefp is t,
for the reason explained below.
If we cannot turn the :function-params into :function-names,
we disambiguate it (into another :function-params) as follows.
We push a new scope for the function prototype [C17:6.2.1/2] [C17:6.2.1/4].
We call a separate function to disambiguate each parameter declaration.
Then, based on the fundefp flag,
we pop the scope (if the flag is nil),
or we leave the scope there (if the flag is t):
in the latter case, this will be the scope of the function definition.
So that is the reason why we push a scope
also in the case, described above,
that we turn :function-params into :function-names:
either way, we are pushing a scope for the function definition.
If the code is valid, the function definition
will indeed have parameter declarations,
and so the disambiguator will do the right thing;
if the code is invalid,
it does not actually matter what the disambiguator does.
