| 1. | An implementation shall support input files
that are a sequence of UTF-8 code units (UTF-8 files). It may also support
an implementation-defined set of other kinds of input files, and,
if so, the kind of an input file is determined in
an implementation-defined manner
that includes a means of designating input files as UTF-8 files,
independent of their content.
If an input file is determined to be a UTF-8 file,
then it shall be a well-formed UTF-8 code unit sequence and
it is decoded to produce a sequence of Unicode8
scalar values. A sequence of translation character set elements ([lex.charset]) is then formed
by mapping each Unicode scalar value
to the corresponding translation character set element. In the resulting sequence,
each pair of characters in the input sequence consisting of
U+000d carriage return followed by U+000a line feed,
as well as each
U+000d carriage return not immediately followed by a U+000a line feed,
is replaced by a single new-line character. For any other kind of input file supported by the implementation,
characters are mapped, in an
implementation-defined manner,
to a sequence of translation character set elements,
representing end-of-line indicators as new-line characters. |
| 2. | Each sequence of a backslash character (\)
immediately followed by
zero or more whitespace characters other than new-line followed by
a new-line character is deleted, splicing
physical source lines to form logical source lines. Only the last
backslash on any physical source line shall be eligible for being part
of such a splice. [Note 2: — end note]
A source file that is not empty and that (after splicing)
does not end in a new-line character
shall be processed as if an additional new-line character were appended
to the file. |
| 3. | The source file is decomposed into preprocessing
tokens ([lex.pptoken]) and sequences of whitespace characters
(including comments).
Each comment ([lex.comment]) is replaced by one space character. New-line characters are
retained. Whether each nonempty sequence of whitespace characters other
than new-line is retained or replaced by one space character is
unspecified. As characters from the source file are consumed
to form the next preprocessing token
(i.e., not being consumed as part of a comment or other forms of whitespace),
except when matching a
c-char-sequence,
s-char-sequence,
r-char-sequence,
h-char-sequence, or
q-char-sequence,
universal-character-names are recognized ([lex.universal.char]) and
replaced by the designated element of the translation character set ([lex.charset]). The process of dividing a source file's
characters into preprocessing tokens is context-dependent. [Example 1: — end example] |
| 4. | Preprocessing directives ([cpp]) are executed, macro invocations are
expanded ([cpp.replace]), and _Pragma unary operator expressions are executed ([cpp.pragma.op]). A #include preprocessing directive ([cpp.include]) causes the named header or
source file to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted. |
| 5. | For a sequence of two or more adjacent string-literal preprocessing tokens,
a common encoding-prefix is determined
as specified in [lex.string]. Each such string-literal preprocessing token is then considered to have
that common encoding-prefix. |
| 6. | |
| 7. | Each preprocessing token is converted into a token ([lex.token]). Whitespace characters separating tokens are no longer significant. The resulting tokens constitute a translation unit and
are syntactically and
semantically analyzed as a translation-unit ([basic.link]) and
translated. [Note 3: The process of analyzing and translating the tokens can occasionally
result in one token being replaced by a sequence of other
tokens ([temp.names]). — end note]
It is
implementation-defined
whether the sources for
module units and header units
on which the current translation unit has an interface
dependency ([module.unit], [module.import])
are required to be available. [Note 4: Source files, translation
units and translated translation units need not necessarily be stored as
files, nor need there be any one-to-one correspondence between these
entities and any external representation. The description is conceptual
only, and does not specify any particular implementation. — end note] |
| 8. | Translated translation units and instantiation units are combined
as follows:
Each translated translation unit is examined to
produce a list of required instantiations. [Note 6: This can include
instantiations which have been explicitly
requested ([temp.explicit]). — end note]
The definitions of the
required templates are located. It is implementation-defined whether the
source of the translation units containing these definitions is required
to be available.
All the required instantiations
are performed to produce
instantiation units.
The
program is ill-formed if any instantiation fails. |
| 9. |