Correct 2 x grammar rules for compilation unit name in #line

[RexJaeschke]

Good catch, @logeshkumars0604!

This PR addresses Issue #1118.

The " vs. # error was introduced in V6 when we converted to the ANTLR grammar notation.

The ability to have an empty filename was never tested, but as you point out, it does work, so I have made the name contents zero-or-more characters, instead of one-or-more. I tested this using #line 300 "" along with CallerFilePathAttribute.

[Nigel-Ecma]

Probably need to expand the changes here, or spin of a new issue/PR to fix more.

[Nigel-Ecma]

We should check this is by design before making this change. Regardless of the answer there is probably some work to do:

• §14.2 Compilation units defines a compilation unit, the definition does not include them having names… or being files… However the example (non-normative) uses two files A.cs and B.cs and refers to them as two compilation units.
• §22.5.6.3 The CallerFilePath attribute which provides the file path (which is implementation-dependent) states “The file path may be affected by #line directives ([§6.5.8]”.
• Here in §6.5.8 the #line allows the setting of the “compilation unit name”
• So:
  • §6.5.8 states compilation units have names, which is omitted in §14.2; and
  • §22.5.6.3 tells us that the name is the file path, but leaves what that is implementation-dependent

What already exists isn’t overly clear and this change seeks to allow the compilation unit name to be the empty string, which is probably not a valid implementation-dependent path on any implementation… So if this
observed compiler behaviour is by design then it surely needs to have a defined meaning in the Standard.

If this change is to be made, and even if not, this all needs to tided up – either in this PR or spin it all off into a new one.

---

I might ask what the intended use of an empty file path/compilation unit name is but I might know – it was requested by the NSA so that the file names in NSA distributed software is not leaked and so endanger National Security! I’m only partially joking here, but that’s a story for another time ;-)

[RexJaeschke]

@BillWagner told me that allowing an empty string was indeed a conscious decision, so I propose keeping that edit.

[RexJaeschke]

@Nigel-Ecma

§6.1 Programs states:

A C# program consists of one or more source files, known formally as compilation units (§14.2). Although a compilation unit might have a one-to-one correspondence with a file in a file system, such correspondence is not required.

I propose appending to this, the following:

… As such, the accepted spelling of a compilation unit name, and its mapping, if any, to a filename is outside the scope of this specification.

I'm deliberately avoiding using any of the following terms:

• behavior, implementation-defined – unspecified behavior where each implementation documents how the choice is made
• behavior, undefined – behavior, upon use of a non-portable or erroneous construct or of erroneous data, for which this specification imposes no requirements
• behavior, unspecified – behavior where this specification provides two or more possibilities and imposes no further requirements on which is chosen in any instance

[Nigel-Ecma]

The # was a typo so should be fixed…

However §22.5.6.3 defines the format of the compilation unit name/file path as “implementation-dependent”. So this section might need a semantic rule saying this arbitrary string must conform to the same implementation-dependent rules §22.5.6.3, or that is does not need to (i.e. not be valid as a file path).

[BillWagner]

closing and reopening to rerun the CI builds.

[RexJaeschke]

6.5.8 Line directives, states

Line directives may be used to alter the line numbers and compilation unit names that are reported by the compiler in output such as warnings and errors.

Note the presence of "reported": there is no requirement that such a reported name map to anything in a file system, so why not allow an empty string name?

[RexJaeschke]

From the 2024-09-04 TG2 call:

There appear to be 2 issues:

1. Conflicting text for the existing grammar.
2. Whether we want to allow an empty string. Just because Roslyn allows it is not necessarily a reason for the spec to do so.

After a short discussion, Rex agreed to take another look.