Unclear whether EmbeddedText with empty filePath is allowed

[jcouv]

The documentation on EmbeddedText says that empty file path is allowed. But there is no way to create an EmbeddedText with an empty file path.

In EmbeddedText:

        /// <summary>
        /// The path to the file to embed.
        /// </summary>
        /// <remarks>See remarks of <see cref="SyntaxTree.FilePath"/></remarks>
        public string FilePath { get; }

which refers to:

        /// <summary>
        /// The path of the source document file.
        /// </summary>
        /// <remarks>
        /// If this syntax tree is not associated with a file, this value can be empty.
        /// The path shall not be null.
...
        /// </remarks>
        public abstract string FilePath { get; }

But all the factory methods for EmbeddedText throw if the file path is empty:

        /// <exception cref="ArgumentNullException"><paramref name="filePath"/> is null.</exception>
        /// <exception cref="ArgumentException"><paramref name="filePath"/> is empty.</exception>
        private static void ValidateFilePath(string filePath)
 ...

And the private constructor for EmbeddedText asserts that the file path is not empty:

        private EmbeddedText(string filePath, ImmutableArray<byte> checksum, SourceHashAlgorithm checksumAlgorithm, ImmutableArray<byte> blob)
        {
            Debug.Assert(filePath?.Length > 0);

Tagging @tmat

For context, I am trying to modify our test helper CompileAndVerify to embed symbols and source into the produced assembly.

Relates to #12625 (Proposal: Embed sources in PDBs)

[jaredpar]

CC @nguerrera as well.

[jcouv]

Note: in PR #31679, I'm relaxing this, so that EmbeddedText is consistent with SyntaxTree.FilePath.
I'm currently waiting on a new build of dev16 preview2 to validate end-to-end scenario (debugging with some embedded source that has a blank file name).

[jcouv]

Confirmed that the file path in EmbeddedText should not be left blank. If it is blank, the debugger will not be able to find and display it (even if there is a match on the hash code).
The linked PR ended up just clarifying the comment.
Closed the issue