Runtime: Span: Add debugger viewers to Span<T> and ReadOnlySpan<T>

[KrzysztofCwalina]

It's difficult to debug programs that use spans because the span items cannot be easily inspected in the debugger.

[AlexGhiondea]

@ahsonkhan is this something you are working on?

[ahsonkhan]

Not atm. Would you like me to tackle it?

[AlexGhiondea]

I marked it as up for grabs. If you have time to work on it, then let me know and I will assign it to you!

[felipepessoto]

Hi @karelz, I plan to work on it with a colleague. Have you defined if we need to Override ToString, add debugger viewer or both?

Thanks

[karelz]

@KrzysztofCwalina @jkotas can comment which solution is better ...

[jkotas]

The debugger viewer is the important one to have.

I am not sure what ToString would do to be useful. Span is essentially a collection type. We do not have ToString overrides on collection types in general.

[felipepessoto]

@mramosMS will fix this issue. Thanks

[karelz]

@mramosMS I sent you collaboration invite. Once you accept (ping me when you do it), I will be able to assign the issue to you (GitHub restrictions/policy).

[karelz]

@mramosMS are you still working on it?

[mramosMS]

Yes, I will work on that the second week of February.

@mramosMShttps://github.com/mramosMS are you still working on it?

[felipepessoto]

I was trying to use my own build of System.Memory (unsuccessfully btw) and figure out that we have two implementations: https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System/Span.cs and https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Span.cs.

How does it work?

Thanks

[felipepessoto]

Hi guys, after building CoreFX, I can't find System.Memory package. Do you know how to generate it?

I just found the DLL (at "corefx\bin\runtime\netcoreapp-Windows_NT-Debug-x64\System.Memory.dll"). So, I'm copying it manually to System.Memory package cache folder "C:\Users\myuser.nugetpackages\System.Memory\4.4.0-beta-24913-01\lib\netstandard1.0".

It works and I can use it to debug on Visual Studio and see how the debug view works. But it is ugly :)

[karelz]

@ahsonkhan @jkotas can you please help?

[ahsonkhan]

I was trying to use my own build of System.Memory (unsuccessfully btw) and figure out that we have two implementations: https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System/Span.cs and https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/Span.cs.

How does it work?

For a netcoreapp, the System.Memory project contains some Span APIs that type forward to the implementation in mscorlib (Fast Span).
For a netstandard, the Span APIs are implemented within System.Memory/.../Span.cs (Slow Span).

The System.Memory csproj file should help clarify since it is a partial facade: https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System.Memory.csproj#L29

If you look at the Manifest of the System.Memory.dll that gets built, you will see the type forwarding:

[ahsonkhan]

@fujiy, @mramosMS, does this unblock you to get further? Feel free to ask more questions.

[felipepessoto]

I sent my workaround to @mramosMS, I think it worked for him.

[mramosMS]

The Workaround worked to debug the application !!. What is required is to implement DebuggerTypeProxy ?

I sent my workaround to @mramosMShttps://github.com/mramosMS, I think it worked for him.

[ahsonkhan]

@KrzysztofCwalina, do you have any insights on implementing DebuggerTypeProxy?

[KrzysztofCwalina]

I implemented such proxy some time ago. It did not work. There was an issue in the debugger that prevented it from working. I don't think the issues have been resolved.

[felipepessoto]

@KrzysztofCwalina we are thinking to implement something like https://github.com/dotnet/corefx/blob/master/src/System.Collections/src/System/Collections/Generic/HashSet.cs#L49
and https://github.com/dotnet/corefx/blob/master/src/System.Collections/src/System/Collections/Generic/ICollectionDebugView.cs

[KrzysztofCwalina]

@fujiy, which particular part are you thinking about implementing? the proxy? If yes, I do understand how proxies work. The particular implementation of the proxy for Span\

Possibly there is a different way to implement the proxy, but I am not sure what would make the interpreter work.

[felipepessoto]

Got it. We can try some different ways to retrieve the collection.
Besides the Items and the Length, there is something else we need to expose?

[felipepessoto]

@ahsonkhan for netcoreapp 1.0 the Slow Span is also used?
To test the netcoreapp 2.0 implementation I think we need to follow these steps: https://github.com/dotnet/coreclr/blob/master/Documentation/workflow/UsingYourBuild.md, right?

I can't figure out how to generate the System.Memory package

Thanks

[felipepessoto]

@mramosMS, as @KrzysztofCwalina said, most of methods in Span class don't work when called by the debugger interpreter, so I implemented the proxy exposing the _pinnable variable with success. (System.Memory version, the netcoreapp uses mscorlib and the implementation is different)

I found a way to test it more easily, instead of changing CoreFX source code, I implemented it with a class in my Console project using a Global Attribute:

[assembly: DebuggerTypeProxy(typeof(MySpanDebugView<>), Target = typeof(Span<>))]

[assembly: DebuggerTypeProxy(typeof(MySpanDebugView<>), Target = typeof(Span<>))]
[assembly: DebuggerDisplay("My Count = {Length}", Target = typeof(Span<>))]
namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            int[] src = { 10, 2, 3 };

            Span<int> srcSpan = new Span<int>(src);

            Console.ReadLine();
        }
    }

    public class MySpanDebugView<T>
    {
        private readonly Span<T> _collection;

        public MySpanDebugView(Span<T> collection)
        {
            _collection = collection;
        }

        [DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
        public object Items
        {
            get
            {
                var field = typeof(Span<T>).GetField("_pinnable", BindingFlags.NonPublic | BindingFlags.GetField | BindingFlags.Instance);
                var value = field.GetValue(_collection);
                return value;
            }
        }
    }
}

So I can build/test/debug quickly.

When implementing inside Span class you could remove the Reflection code:

/// <summary>
   /// Span debug view
   /// </summary>
    public class MySpanDebugView<U>
    {
        private readonly Span<U> _collection;

        /// <summary>
        /// Span debug view
        /// </summary>
        public MySpanDebugView(Span<U> collection)
        {
            _collection = collection;
        }

        /// <summary>
        /// Span debug view
        /// </summary>
        [DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
        public object Items
        {
            get
            {
                return _collection.Pinnable;
            }
        }
    }

/// <summary>
/// Span represents a contiguous region of arbitrary memory. Unlike arrays, it can point to either managed
/// or native memory, or to memory allocated on the stack. It is type- and memory-safe.
/// </summary>
[DebuggerDisplay("My Length = {Length}")]
[DebuggerTypeProxy(typeof(MySpanDebugView<>))]
public struct Span<T>
{   
....

Let me know if it works for you.

[KrzysztofCwalina]

@jkotas, will getting _pinnable through reflection actually pin the buffer?

[felipepessoto]

@KrzysztofCwalina it is just the test I made to find out how expose the values, it's easier because I didn't need to recompile System.Memory/mscorlib.

The actual implementation shouldn't use reflections.

[KrzysztofCwalina]

Ah, sorry. I missed that.

[jkotas]

@jkotas, will getting _pinnable through reflection actually pin the buffer?

It will not. Pinnable is a regular type, there is nothing that would pin it implicitly.

I think making this work for fast Span is more important than making this work for slow Span. Fast Span does not even have _pinnable.

I doubt that you will be able to make this work by just writing a debugger display proxy. I expect that the VS debugger expression eval part will need some fixes to make this work.

[felipepessoto]

Can we go ahead with only Slow Span, for now?

[KrzysztofCwalina]

I think it would be ok to start with the slow span, but we need to have a solution for fast span too. It would be bad if we regressed debugger support when going from the "worse" span to the "better" one.

Also, the proxy that you have above does not really show the data in the span (logical span). For example, if you create an array of 100 items, wrap it in a span, slice the span to 10 items, the proxy would still show 100 items.

[felipepessoto]

@KrzysztofCwalina after we finish the Slow Span, @mramosMS and I will try to implement a workaround to Fast Span too.

It is still a naive implementation, but worked in my tests, with both Spans built from objects and pointers. We are still learning how Span and DebuggerTypeProxy works :)

I still need to figure out why calling _pinnable using reflection return an array and when calling it through _collection.Pinnable doesn't allow me to cast it to array:

internal sealed class SpanDebugView<T>
{
    private readonly T[] _pinnable;
    private readonly IntPtr _byteOffset;
    private readonly int _length;

    public SpanDebugView(Span<T> collection)
    {
        _pinnable = (T[])(object)collection.Pinnable;
        _byteOffset = collection.ByteOffset;
        _length = collection.Length;
    }

    [DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
    public unsafe T[] Items
    {
        get
        {
            int elementSize = typeof(T).IsValueType ? Unsafe.SizeOf<T>() : IntPtr.Size;

            if (_pinnable == null)
            {
                var result = new T[_length];
                byte* source = (byte*)_byteOffset.ToPointer();
                byte* fixedResult = (byte*)Unsafe.AsPointer(ref result[0]);

                int totalSize = _length * elementSize;

                for (int i = 0; i < totalSize; i++)
                {
                    *fixedResult = *source;
                    fixedResult++;
                    source++;
                }

                return result;
            }
            else
            {
                var _byteOffsetInt32 = _byteOffset.ToInt32();
                var sourceIndex = (_byteOffsetInt32 - IntPtr.Size) / elementSize;

                var result = new T[_length];

                Array.Copy(_pinnable, sourceIndex, result, 0, _length);

                return result;
            }
        }
    }
}

@mramosMS, when testing you can use a even simpler way:

1-) Build corefx for netfx: "build -framework=netfx"
2-) Create a .NET 4.6.1 project
3-) Reference the System.Memory.dll, netstandard.dll, System.Runtime.CompilerServices.Unsafe.dll and in corefx\bin\runtime\netfx-Windows_NT-Debug-x64 folder.
4-) After you first corefx build, you can just change the code and build the System.Memory project running "msbuild /p:TargetGroup=netfx" in corefxsrc\System.Memorysrc

PS: I didn't test with reference types

Thanks

[felipepessoto]

Here is a working draft of Fast Span DebuggerTypeProxy, including sliced Span:

public class MySpanDebugView<U>
{
    private readonly Span<U> _collection;

    public MySpanDebugView(Span<U> collection)
    {
        _collection = collection;
    }

    [DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
    public unsafe U[] Items
    {
        get
        {
            int elementSize = Unsafe.SizeOf<U>();
            int length = _collection.Length;

            var result = new U[length];

            var _pointer = _collection.GetType().GetField("_pointer", BindingFlags.NonPublic | BindingFlags.GetField | BindingFlags.Instance).GetValue(_collection);
            var byReferenceType = _pointer.GetType();
            var _value = (IntPtr)byReferenceType.GetField("_value", BindingFlags.NonPublic | BindingFlags.GetField | BindingFlags.Instance).GetValue(_pointer);
            byte* source = (byte*)_value.ToPointer();

            byte* fixedResult = (byte*)Unsafe.AsPointer(ref result[0]);

            int totalSize = length * elementSize;

            for (int i = 0; i < totalSize; i++)
            {
                *fixedResult = *source;
                fixedResult++;
                source++;
            }

            return result;
        }
    }
}

[ahsonkhan]

@noahfalk, what do you think?

[felipepessoto]

If it is okay I will work with @mramosMS to send a PR.

[jkotas]

public class MySpanDebugView<U>
{
    private readonly Span<U> _collection;

Span is stack-only type. It cannot be a field of a class. If you try to run this with fast Span on current CoreCLR, you should see TypeLoadException: A value type containing a by-ref instance field, such as Span<T>, cannot be used as the type for a class instance field.. It will be enforced by the C# compiler as well so this won't even compile by the time we are done.

[noahfalk]

The local field issue I assume is avoidable by eagerly unpacking Span in the constructor and storing a U[] of items in the field instead.

I don't recall the extent of VIL's reflection support, but presumably if that is an issue we can replace it with nested internal types that can access private fields in ByReference and Span respectively.

I'd be a little suspicious if VIL can handle the Unsafe.* intrinsics either. @plnelson @gregg-miskelly probably know how well that works.

@jkotas were there any other particular issues you forsaw here? I haven't looked this over much yet.

[felipepessoto]

@jkotas, you are right, but I don't know how it is actually working in VS2017.

@noahfalk, I intend to remove reflection in final implementation. I'm using reflection because I'm testing using a type proxy declared in my Console project, so I don't need to recompile CoreClr every time.

[plnelson]

VIL (the debugger's IL interpreter) supports most of the Reflection methods. The only exceptions are reflection methods that get information that is not available in metadata - Type.IsComObject for example. I also took a quick look at the CoreFx source for Unsafe.Sizeof and Unsafe.AsPointer. VIL should be able to handle both of these.
The best way to test this is to save a dump of your test app, then try evaluating the Span instance when debugging the dump.

[KrzysztofCwalina]

@plnelson, what about the idea for "unpacking" the span in the ctor of the proxy? Won't this prevent changes to the span data to be reflected in the debugger? i.e. how often does the debugger create a new proxy?

[KrzysztofCwalina]

@fujiy, it would be better if you used span APIs to get to the data. See this line of code for an example:
https://github.com/dotnet/corefxlab/blob/82e6bbc92641547c588c9e9d474d5b3d51d0a0c8/src/System.Text.Primitives/System/Text/Encoding/Ascii/PrimitiveEncoder_ascii.cs#L48

[felipepessoto]

@KrzysztofCwalina I tried, but it didn't work on VIL. I can try again with VS2017 RTM

[plnelson]

@KrzysztofCwalina, not sure what you mean by "unpacking the span". Looks like the .ctor in the snippet is saving an array reference to a field.
For your other question, the type proxy is created every time the value is evaluated. Essentially this means every time you step and the value is visible in one of the debugger windows.

[KrzysztofCwalina]

@plnelson, it's saving the Span, not "an array". Spans cannot be stored in fileds of reference types, so the snippet won't work. The suggestion was that instead of storing the span, the ctor would make copy of the data (basically execute the code that currently is in the Items property), and store the copied array.

[plnelson]

@KrzysztofCwalina I see, for some reason I read array vs. span. Why can't a span be stored in a field? Is it because the "pointer" field of the span can potentially contain a reference to a stack location?
Anyway, having the Items property copy the data would also work.

[felipepessoto]

Maybe it work in our context. At least my DebuggerTypeProxy is working

[ahsonkhan]

@fujiy, do you have a PR for this?

[felipepessoto]

Hi @ahsonkhan, @mramosMS is working on it.
Do we have a deadline? I don't know how is the @mramosMS availability.
Thanks

[ahsonkhan]

@fujiy, there isn't a deadline, I was just pinging for an update since it had been a while. Keep going :)

[felipepessoto]

@ahsonkhan, @karelz just announced the ZBB date (May 10). We need to send the PR before that?
I talked with @mramosMS and he probably can't continue the work before May 22.

In case we need it before, I will send the PR by myself

[karelz]

The bug is marked 2.0, so we need it for ZBB. If you can help with it earlier, that would be great, otherwise I assume that @ahsonkhan will take it over.

[ahsonkhan]

In case we need it before, I will send the PR by myself

That would be awesome.

[felipepessoto]

@ahsonkhan, is it ok to implement it with something like the workaround I wrote above, considering the VIL limitations?

[ahsonkhan]

is it ok to implement it with something like the workaround I wrote above, considering the VIL limitations?

I am not really sure about this. Maybe @KrzysztofCwalina, @plnelson, @jkotas, can provide some insight.

Was this comment by Jan addressed?

public class MySpanDebugView<U>
{
    private readonly Span<U> _collection;

Span is stack-only type. It cannot be a field of a class. If you try to run this with fast Span on current CoreCLR, you should see TypeLoadException: A value type containing a by-ref instance field, such as Span<T>, cannot be used as the type for a class instance field.. It will be enforced by the C# compiler as well so this won't even compile by the time we are done.

[plnelson]

is it ok to implement it with something like the workaround I wrote above, considering the VIL limitations?

I don't know off the top of my head. I would suggesting testing it by evaluating a Span value from the Watch window using the ,emulator format specificer. For example - mySpanValue,emulator. If you run into problems, I can help investigate what VIL doesn't like about it.

[felipepessoto]

@plnelson, the whole workaround is because ToArray() does not work:

mySpanValue.ToArray(),emulator
The debugger is unable to evaluate this expression

The same happens to mySpanValue.DangerousGetPinnableReference(),emulator, or any other method, even the Clear method.

If I try to just return the reference to Span in my DebuggerTypeProxy, VS crashes:

[jkotas]

We will need to work with VS debugger team to make this work. I have said above: I doubt that you will be able to make this work by just writing a debugger display proxy. I expect that the VS debugger expression eval part will need some fixes to make this work.

[plnelson]

The debugger work is tracked by internal bug 286592

[felipepessoto]

Do you believe it will be fixed in the next days?

[felipepessoto]

Was this comment by Jan addressed?

public class MySpanDebugView<U>
{
    private readonly Span<U> _collection;

Span is stack-only type. It cannot be a field of a class. If you try to run this with fast Span on current CoreCLR, you should see TypeLoadException: A value type containing a by-ref instance field, such as Span, cannot be used as the type for a class instance field.. It will be enforced by the C# compiler as well so this won't even compile by the time we are done.

We will change it before sending the PR (if we agree to go ahead with the workaround approach)

[plnelson]

Do you believe it will be fixed in the next days?

This isn't the kind of thing we can fix in a few days. @caslan may know when this work can be scheduled.

[felipepessoto]

I see. May I go ahead with the workaround?

[felipepessoto]

@plnelson this command returns the incorrect result:

Unsafe.SizeOf<object>(), emulator

Returns 0, instead of IntPtr.Size

PS: It happens to any class. It returns the size of the fields instead of the reference size

[plnelson]

Unsafe.SizeOf<object>(), emulator returns 0

Unsafe is not special-cased in VIL as it is in the Core CLR EE. I would actually expect it to throw InvalidOperationException, because that's implementation I see in Unsafe.cs. Either way, this is not going to work unless we add special casing for all of these methods.

[jkotas]

This is using Unsafe.SizeOf implementation from https://github.com/dotnet/corefx/blob/master/src/System.Runtime.CompilerServices.Unsafe/src/System.Runtime.CompilerServices.Unsafe.il#L154. You should not need any special casing for this one. The sizeof IL opcode just needs to be treated correctly by VIL.

[plnelson]

Thanks @jkotas. Opened internal bug 402754.

[felipepessoto]

Hi guys, I'm afraid I can't make it work for Fast as I thought.

I worked in my tests, where I write de Debug Type proxy in my console app. But when I copy the same code to CoreClr and build it, i doesn't work. VS just says that can't evaluate it.

[ahsonkhan]

Hi guys, I'm still trying to make FastSpan Debug Viewer works.
How do I create the type forward for new types? I added a SpanDebugView (that ends up at System.Private.CoreLib.ni.dll), but can't reference it my code to debug, because corefx\bin\Windows_NT.AnyCPU.Debug\System.Memory\netcoreapp\System.Memory.dll doesn't contain that type or the type forward.
I also didn't find the NuGet Packages for System.Memory

The package is on myget currently:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Memory

For type forwarding, look at the csproj and ref assembly:
https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System.Memory.csproj
https://github.com/dotnet/corefx/blob/master/src/System.Memory/ref/System.Memory.cs

You will likely need to add the type in coreclr as well:
https://github.com/dotnet/coreclr/tree/master/src/mscorlib/src/System

[felipepessoto]

Hi @ahsonkhan. I did that to Slow Span. But I didn't figure out how System.Memory.dll for Fast Span is built (the one used at runtime). How it generates the type forward to System.Private.CoreLib. It currently contains type-forward just for Span and ReadOnlySpan

The best guess I have is that it generates autommatically. But I still didn't figure out how to make corefx build consume the packages generated by my coreclr build.

Here is explained (a bit outdated) how to do that, but I don't want to (and won't be able) to send a PR to CoreClr and wait you merge it, before I know if it will work. https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/adding_new_public_apis.md

[jkotas]

The best guess I have is that it generates autommatically

Correct. IsPartialFacadeAssembly in .csproj file triggers it.

But I still didn't figure out how to make corefx build consume the packages generated by my coreclr build.

https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/developer-guide.md#testing-with-private-coreclr-bits

[ahsonkhan]

@fujiy, do you have any updates for fast span or maybe some more questions?

[felipepessoto]

I'm still trying to build coreclr/corefx with 2017 without success, my computer has just 100GB so I can't install both 2015 and 2017.
https://github.com/dotnet/coreclr/issues/10890

[ahsonkhan]

Are you able to build using the command line instead?

Edit: Ignore, I just saw the issue you linked to.

[felipepessoto]

Do you know why when running the application it loads the System.Private.CoreLib.ni.dll from

packages\runtime.win-x64.microsoft.netcore.app\2.0.0-preview2-002066-00\runtimes\win-x64\native

Instead of

packages\runtime.win7-x64.microsoft.netcore.runtime.coreclr\2.0.0-preview2-25210-0\runtimes\win7-x64\native

I didn't find out how to generate the Microsoft.NerCore.App package

[felipepessoto]

@ahsonkhan I guess I can't implement it to Fast Span, because VIL doesn't support calling methods from Unsafe class, they are implemented by EE, e.g.:

    /// <summary>
    /// Returns a pointer to the given by-ref parameter.
    /// </summary>
    [NonVersionable]
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static void* AsPointer<T>(ref T value)
    {
        // The body of this function will be replaced by the EE with unsafe code!!!
        // See getILIntrinsicImplementationForUnsafe for how this happens.  
        throw new InvalidOperationException();
    }

I also tried to use GCHandle without success

[ahsonkhan]

I didn't find out how to generate the Microsoft.NerCore.App package

@mellinoe, can you help with clarifying this?

I guess I can't implement it to Fast Span, because VIL doesn't support calling methods from Unsafe class, they are implemented by EE.

@jkotas, @plnelson, is this something that we need the VS debugger team to help with?

[felipepessoto]

@ahsonkhan, @plnelson created an internal bug 286592, I don't know if it includes the methods generated by EE.

I'm facing some issues using my coreclr build, when I run dotnet publish and execute the result, I receive:

Failed to initialize CoreCLR, HRESULT: 0x80004005

I could make it work copying the content of my coreclr\bin\Product\Windows_NT.x64.Debug to myapp\bin\Debug\netcoreapp2.0\win7-x64publish folder.

I also couldn't find out how to generate System.Memory package, so I'm manually replacing the dll in Nuget cache folder and publish folder.

[jkotas]

@jkotas, @plnelson, is this something that we need the VS debugger team to help with?

Yes. I have said above: "I doubt that you will be able to make this work by just writing a debugger display proxy. I expect that the VS debugger expression eval part will need some fixes to make this work."

[ahsonkhan]

From @KrzysztofCwalina

@ahsonkhan, what's the plan if we cannot fix the debugger before we ship System.Memory? Would we live or remove the proxy? If we leave it (hoping that the debugger will catch up), should/could we convert the exception to something more explanatory?

From @ahsonkhan

I don't know if we can convert the exception to something more explanatory, if we leave the SpanDebugView as is.
If we explicitly throw a meaningful exception in the SpanDebugView then we would have to revert that when the VS debugger catches up.
Calling ToArray calls the JIT intrinsics and that is resulting in the debugger view error.
https://github.com/dotnet/coreclr/blob/master/src/mscorlib/shared/System/ReadOnlySpan.cs#L316
C# Span.CopyTo<T>(ref Unsafe.As<byte, T>(ref destination.GetRawSzArrayData()), ref _pointer.Value, _length);

cc @caslan

[ianhays]

There appear to be two distinct work items in this issue:

• Implement ToString on Span/ReadOnlySpan and have it print out a string similar to what a collection would print out.
  
  
  
  • This is easy and should be done regardless of the debuggerdisplayproxy.
  
  
• Add Debugger viewers for Span/ReadOnlySpan
  
  
  
  • The naive solution is to implement a DebuggerTypeProxy that uses ToArray() on the Span/ReadOnlySpan. This is currently failing due to internal bug #286592 in the VS debugger.
  
  
  • It looks like we spent a bunch of time trying to work around ToArray() failing in the DebuggerTypeProxy only to end up with a complex workaround that also requires improved VS support. Is that accurate?
  
  
  • If so, then we should go back to our original naive solution and implement a DebuggerTypeProxy using ToArray. This is the correct approach and our time would be better spent fixing the VS bug than trying to work around it in a convoluted way.
  
  
  • The main concern then becomes what happens to people debugging on a version of VS that doesn't have the debugger fix. From the above comments, it appears to cause a hard crash. We need to decide whether:
  
  
  • this is acceptable
  
  
  • this needs to be worked around on our end somehow
  
  
  • older VS versions need to be patched with the debugger fix
  
  
  • breaking older VS versions in such a manner is worth fixing the display in the next version or if we should just do nothing.
  
  

@ahsonkhan @jkotas @fujiy does that sound like an accurate representation of the current state of this issue?

[ahsonkhan]

It looks like we spent a bunch of time trying to work around ToArray() failing in the DebuggerTypeProxy only to end up with a complex workaround that also requires improved VS support. Is that accurate?

The workaround works without any update to the VS debugger for "portable" span. The internal bug in the VS debugger is blocking "fast span" debugging only which currently uses the naive solution:
https://github.com/dotnet/coreclr/blob/master/src/mscorlib/shared/System/SpanDebugView.cs#L17

Implement ToString on Span/ReadOnlySpan and have it print out a string similar to what a collection would print out.

I am not sure if we can implement ToString on Span. See related issue: https://github.com/dotnet/corefx/issues/21629#issuecomment-311789157

[jkotas]

Implement ToString on Span/ReadOnlySpan and have it print out a string similar to what a collection would print out.

I do not think framework collections override ToString. E.g. List<T> does not have ToString over-ridden. Also, Span is more equivalent to array - and array does not override ToString either.

[ianhays]

I am not sure if we can implement ToString on Span. See related issue: dotnet/corefx#21629 (comment)
I do not think framework collections override ToString. E.g. List does not have ToString over-ridden. Also, Span is more equivalent to array - and array does not override ToString either.

Looks like https://github.com/dotnet/coreclr/pull/15745 made the error here more helpful at least, so we can leave that as-is.

The workaround works without any update to the VS debugger for "portable" span. The internal bug in the VS debugger is blocking "fast span" debugging only which currently uses the naive solution:

In that case, what else is there that needs to be done in CoreFX?

[KrzysztofCwalina]

Looks like dotnet/coreclr#15745 made the error here more helpful at least, so we can leave that as-is.

and

I do not think framework collections override ToString. E.g. List does not have ToString over-ridden. Also, Span is more equivalent to array - and array does not override ToString either.

I don't understand why we would not override ToString. For the sake of consistency with arrays and List? Is this consistency useful? Does it add value?

On the other hand, it's close to impossible to debug code using spans. ToString override would not fix the overall issue (we still need to fix the debugger), but it would improve the situation a lot. I really worry that the current situation will seriously hamper the adoption of Span.

cc: @terrajobst, @joshfree

[jkotas]

For the sake of consistency with arrays and List? Is this consistency useful? Does it add value?

I think that the main problem is that there is no decent way to implement universal formatter for lists if you do not know what the items are. E.g. what would you use for seperators? Spaces, commas, new-lines, ...?

but it would improve the situation a lot.

How would it improve the situation? To make Console.Write debugging easier?

[ianhays]

I'm splitting this issue so the DebuggerTypeProxy discussion doesn't get lost in the ToString discussion.

Please continue discussion on ToString over in https://github.com/dotnet/corefx/issues/26295

[ianhays]

On the latest version of the VS preview this is now fixed for the fast span using its current implementation.

[felipepessoto]

After the fix been released, should we "simplify" the slow span debugger proxy version?

https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System/SpanDebugView.cs

[ahsonkhan]

After the fix been released, should we "simplify" the slow span debugger proxy version?

Yes! Ian and I discussed this already and he plans to simplify it to just a ToArray call, similar to what Fast Span does atm.
https://github.com/dotnet/coreclr/blob/master/src/mscorlib/shared/System/SpanDebugView.cs#L26