Rough draft of Section 3.5 conditionals: #if, #elif, etc. #61
Conversation
|
Apparently, Gary does not know how to do a squash commit. |
|
From email sent to the team, which may be useful for reviewers: This PR covers only the directives in the #if family. As these directives are highly interdependent, I didn’t write a separate section on each directive. Instead, there is a single omnibus illustrative syntax that includes all the directives, and the order and quantity in which they can appear. As with the other directives, there is a subsection on the “static semantics”, the rules that must be followed in the form the directives take. It covers loosely the proper nesting of conditional directives. There is also the customary subsection on “evaluation semantics”: what happens when we act on the directives. Nesting syntax and semantics get a bit complicated. There is some text about that, but it is not as formal as I would like. (I may have to wait until the syntax paper to spell it out in detail.) |
Co-authored-by: Dan Bonachea <[email protected]>
Co-authored-by: Dan Bonachea <[email protected]>
Co-authored-by: Dan Bonachea <[email protected]>
Add di00 to clarify directive name recognition as "token immediately following '#' introducing a directive line." Use grammar symbols <if-head>, etc., when describing conditional directive processing. Change grammar symbol <lines> to <group> to (slightly) better mirror C 2023 usage. Add specification for skipping <group>s, and used this in subsequent descriptions of <if-head>, <if-elif> and <if-else> constructs. Remove if10. as di00 covers this more generally.
Initial draft of Section 3.5. Added illustrative syntax, static semantics and evaluation semantics, up to but not including controlling expression evaluation. (That will be an another section.)
I tried to use the terminology from the C 2023 standard, but reviewers will surely find lapses and potential improvements.