Roslyn: Compiler emits invalid sequence point when line is longer than 64k

[tmat]

Version Used:

26530.1.d15rel

Steps to Reproduce:

```c#
class Program
{
static void Main(string[] args)
{
var a = "string longer than 64K ...";
Console.WriteLine(a);
}
}

**Expected Behavior**:

Stepping works.

**Actual Behavior**:

The debugger is not able to read the PDB. The sequence point in the PDB is bad:

MethodDebugInformation (index: 0x31, size: 8):

1: 0x30000001 (Document) #ce
{
Locals: 0x11000001 (StandAloneSig)

IL_0000: (12, 9) - (12, 10) 0x30000001 (Document)

}
```

[Ahmed-Raouf]

Try to Enabel .Net Framwork Source Stepping.
Debug => Options => General

[shyamnamboodiripad]

Note that this also impacts the instrumentation that is consumed by Live Unit Testing. Live Unit Testing currently encounters a BadImageFormatException if there are any code files with very long lines.

See https://developercommunity.visualstudio.com/content/problem/207323/liveunittesting-sequencepointvalueoutofrange.html (and linked work items) for more details.

[IhorHolovatsky]

I had the same issue,

as a hotfix, I moved my big string to file, and wrote logic to load string from file

[shyamnamboodiripad]

@jinujoe we are seeing several reports of this on developer community for LUT. Any chance we can get this fixed soon?

Some notes from my earlier investigation -
Live Unit Testing currently encounters a System.BadImageFormatException with message SequencePointValueOutOfRange if there are any code files with very long lines. In the repro project, the crash is happening when LUT tries to decode column offsets for a line that contains a very long string literal that is being used as input to a test.

Looks like the compiler is encoding the column offset as an int - see http://source.roslyn.io/#Microsoft.CodeAnalysis/PEWriter/SourceSpan.cs,16 and http://source.roslyn.io/#Microsoft.CodeAnalysis/PEWriter/MetadataWriter.DynamicAnalysis.cs,167.

However, the data type used for column offsets in DynamicAnalysisDataReader in LUT is ushort (as opposed to int) see https://github.com/dotnet/testimpact/blob/master/src/Aggregator/Aggregator/External/DynamicAnalysisDataReader.cs#L221 and the code throws (see https://github.com/dotnet/testimpact/blob/master/src/Aggregator/Aggregator/External/DynamicAnalysisDataReader.cs#L363) if it encounters anything that can cause an overflow.

Per the pdb spec, columns are supposed to be encoded as ushort (see
https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md#methoddebuginformation-table-0x31 ) So perhaps the compiler should be truncating column offsets for long lines to ushort.MaxValue?

[shyamnamboodiripad]

cc @ManishJayaswal @AbhitejJohn for awareness of the impact on LUT

[jinujoseph]

Moving this to P2