[Version 10.0] Feature support for enhanced #line directives#1564
Draft
RexJaeschke wants to merge 6 commits intodraft-10from
Draft
[Version 10.0] Feature support for enhanced #line directives#1564RexJaeschke wants to merge 6 commits intodraft-10from
RexJaeschke wants to merge 6 commits intodraft-10from
Conversation
RexJaeschke
added
type: feature
RexJaeschke
commented
Feb 5, 2026
standard/lexical-structure.md
Outdated
|
|
||
| *PP_End_Line_Character* represents the end line (*PP_End_Line*) and column (*PP_End_Character*) pair of the mapped file text; for example, `(3,10)`. | ||
|
|
||
| *PP_Start_Line* and *PP_End_Line* are positive integers that specify line numbers. *PP_Start_Character* and *PP_End_Character* are positive integers that specify UTF-16 character numbers. All four of these numbers are 1-based, meaning that the first line of the mapped file and the first UTF-16 character on each line is assigned number 1. |
Contributor
Author
There was a problem hiding this comment.
The two occurrences of "UTF-16" were retained from the MS spec. However, they can probably be removed. See Rex's Unicode-related PR #1103, “Tweak Some Unicode-Related Text.”
- Replaced `*Start_Line_Character*` with `*PP_Start_Line_Character*`. - Replaced the placeholder with two illustrative code blocks: 1. Basic span form — `#line (5,3)-(5,17) "template.dsl"` mapping a generated statement back to the original template. 2. Character offset form — same directive with offset `11` to account for an `output.Add(` prefix. - Removed all 3 "UTF-16" qualifiers: - "UTF-16 character numbers" → "character numbers" - "the first UTF-16 character on each line" → "the first character on each line" - "the number of UTF-16 characters to skip" → "the number of characters to skip"
### Awkward wording in `PP_Start_Line_Character` description **File:** `standard/lexical-structure.md`, line 1564 **What:** The sentence reads: "*PP_Start_Line_Character* represents the start line (*PP_Start_Line*) and column (*PP_Start_Character*) pair of the first character on the line following the directive, which is the mapped file text; for example, `(1,1)`." The clause "which is the mapped file text" is ambiguous — it's unclear whether it modifies "the line following the directive" or "the first character" or the pair itself. The intent (from the feature spec) is that the (line, char) pair specifies a position *in the mapped file*. **Proposed change:** Reword to something like: "*PP_Start_Line_Character* represents a start position in the mapped file, specified as a line (*PP_Start_Line*) and column (*PP_Start_Character*) pair; for example, `(1,1)`. This position corresponds to the first character on the line following the directive in the generated code." ### Missing constraints on span values **File:** `standard/lexical-structure.md`, after line 1568 **What:** The feature spec states ordering constraints on the span values: - *PP_End_Line* shall be greater than or equal to *PP_Start_Line*. - When *PP_Start_Line* equals *PP_End_Line*, *PP_End_Character* shall be greater than *PP_Start_Character*. These ensure the span is well-formed (non-empty, non-inverted). The PR text does not include these constraints. While the existing "The maximum value allowed for `Decimal_Digit+` is implementation-defined" covers upper bounds, the ordering relationship between start and end is a normative requirement that should be stated. **Proposed change:** Add after the paragraph about 1-based numbering (line 1568): "The end position shall not precede the start position: *PP_End_Line* shall be greater than or equal to *PP_Start_Line*, and when *PP_Start_Line* equals *PP_End_Line*, *PP_End_Character* shall be greater than *PP_Start_Character*." ###`§6.5.1` overview bullet for `#line` is now incomplete **File:** `standard/lexical-structure.md`, line 1097 **What:** The overview says: "`#line`, which is used to control line numbers emitted for errors and warnings". With the enhanced form, the directive also controls column/character mapping and source file span information, not just line numbers. **Proposed change:** Update to: "`#line`, which is used to control line numbers and source file mapping emitted for errors and warnings ([§6.5.8](lexical-structure.md#658-line-directives))." Or, more conservatively, leave as-is since "line numbers" is still broadly accurate and the overview is intentionally brief. **Flag for committee discussion.** ### Relationship between enhanced form and existing `#line default` / `#line hidden` descriptions **File:** `standard/lexical-structure.md`, lines 1554–1558 **What:** The existing text says: - "a compiler treats the line *after* the directive as having the given line number (and compilation unit name, if specified)." - "`#line default` directive undoes the effect of all preceding `#line` directives." - "`#line hidden` directive has no effect on the compilation unit and line numbers reported in error messages." The `#line default` description implicitly covers the enhanced form (good). The `#line hidden` description mentions only "line numbers" but not column/span mapping. Since `#line hidden` doesn't affect error reporting at all, this is arguably fine. However, for completeness it could say "source location information" instead. **Proposed change:** Minor — consider updating the `#line hidden` paragraph to say "has no effect on the source location information reported in error messages" instead of "has no effect on the compilation unit and line numbers reported in error messages". ### "mapped file" terminology introduced without definition **File:** `standard/lexical-structure.md`, lines 1562–1566 **What:** The text introduces the phrase "so-called mapped file" and "the mapped file text" and "in the mapped file." This terminology is new to the standard. The existing standard uses "compilation unit name" for the file path specified in `#line`. The term "mapped file" is never formally defined. **Proposed change:** Either define "mapped file" briefly (e.g., "the source file identified by *PP_Compilation_Unit_Name*, referred to as the *mapped file*") or replace with phrasing that refers to *PP_Compilation_Unit_Name* directly.
BillWagner
force-pushed
the
v10-enhanced-line-directives
branch
from
25e955a to
2abbfa5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is Rex's adaptation of the corresponding MS proposal.
We need one or two simple examples for this, preferably not involving Razor. @Bill suggested maybe something to do with .NET regular expression source generators.