Vl-iframe
`ifdef stack frame objects.
This is a product type introduced by defprod.
Fields
- initially-activep — booleanp
- some-thing-satisfiedp — booleanp
- already-saw-elsep — booleanp
- mi-controller — maybe-string
- When set, this iframe is possibly an include guard
and this is the name of the controlling define.
See vl-includeskips.
- mi-filename — maybe-string
- Corresponds to mi-controller; the filename that is
being included.
Iframes ("ifdef frames") are essential in our approach to
handling `ifdef directives. Our main preprocessing function, vl-preprocess-loop, takes three arguments that have to do with handling
ifdefs:
- defines is the current vl-defines-p alist. For now, just
assume that we are able to appropriately keep this list updated as we encounter
defines and undefs.
- activep is a boolean which is true whenever the characters are are now
reading from the file ought to be given to the lexer -- the idea is that when
we encounter an `ifdef whose condition isn't satisfied, we turn off
activep until the closing `endif is encountered.
- istack is a stack of vl-iframe-p objects which explain how to
manage activep as we descend through a nest of `ifdef, `ifndef,
`elsif, `else, and `endif directives.
Let us temporarily ignore nested directives. Then, our task would be to
decide when activep should be turned on during sequences like this:
`if[n]def THING
stuff1
`elsif THING2
stuff2
`elsif THING3
stuff3
`else
stuff4
`endif
The semantics of this (Section 19.4) are essentially: figure out the first
THING that is satisfied, include its stuff, and ignore the rest. So for
instance, if THING2 and THING3 are both satisfied, we still only
want to include stuff2 since it comes first.
To implement this, the basic idea is that when we encounter an `ifdef
or `ifndef directive, we construct an iframe that helps us set
activep correctly. The first two fields of the iframe are:
- some-thing-satisfiedp
- which indicates if any of the THINGs we have seen so far was
satisfied, and
- already-saw-elsep
- which indicates whether we have seen an `else and is used only as a
sanity check to prevent multiple `else clauses.
And as we descend through the above sequences, we update the iframe and
ensure that activep is set exactly when the current THING is
satisfied and no previous THING was satisfied.
But the story is not quite complete yet, because we also have to handle
nested ifdefs. For example, imagine we have:
`ifdef OUTER
...
`ifdef INNER_THING1
stuff1
`elsif INNER2_THING2
stuff2
`else
stuff3
`endif
...
`endif
This is almost the same, except that now we only want to turn on
activep when OUTER is also satisfied. To keep track of this, we
add another field to our iframe objects:
- initially-activep
- which indicates whether activep was set when we encountered the
`ifdef or ifndef for this iframe.
Now, activep should be enabled exactly when:
- (inner criteria): the current THING is satisfied and no previous
THING was sastified, and
- (outer-criteria): initially-activep was also set, i.e., this chunk of
code is not being blocked by some THING in an outer ifdef
tree.
Subtopics
- Vl-iframe-fix
- Fixing function for vl-iframe structures.
- Make-vl-iframe
- Basic constructor macro for vl-iframe structures.
- Vl-iframe-equiv
- Basic equivalence relation for vl-iframe structures.
- Vl-iframe->some-thing-satisfiedp
- Get the some-thing-satisfiedp field from a vl-iframe.
- Vl-iframe->initially-activep
- Get the initially-activep field from a vl-iframe.
- Vl-iframe->already-saw-elsep
- Get the already-saw-elsep field from a vl-iframe.
- Vl-iframe->mi-filename
- Get the mi-filename field from a vl-iframe.
- Vl-iframe->mi-controller
- Get the mi-controller field from a vl-iframe.
- Change-vl-iframe
- Modifying constructor for vl-iframe structures.
- Vl-iframe-p
- Recognizer for vl-iframe structures.
