Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tuple or Args... packs show nothing in the debugger? #286

Open
TurkeyMan opened this issue Dec 5, 2024 · 4 comments
Open

Tuple or Args... packs show nothing in the debugger? #286

TurkeyMan opened this issue Dec 5, 2024 · 4 comments

Comments

@TurkeyMan
Copy link

I use a lot of Args... and there seems to be no way to inspect them in the debugger.
Also Tuple just shows in the debugger as an empty struct. Any way to make these show the proper sequence of values?

@rainers
Copy link
Member

rainers commented Dec 7, 2024

I guess by Args... you mean runtime variable arguments, not template arguments. There is no support for these, but there might be some compiler generated symbols (i.e. starting with '__'). Maybe some appear if you uncheck the Mago option to "hide compiler generated symbols".

Regarding tuples, there is some support for compiler internal tuples, but nothing specific for std.typecons.Tuple. I'm wondering if the __debug* should also be searched for as free function so you can add them without modifying library code.

I haven't tried anything yet, but it would be good if you can provide examples so I don't have to guess your use case.

@TurkeyMan
Copy link
Author

Ah I didn't realise compiler symbols were being hidden, but I guess that makes sense! DMD does make a lot of named temp symbols. I wonder if the debug info has sufficient metadata available to know if the symbol to be hidden is a function argument, and then not hide it in that case?

I'm wondering if the __debug* should also be searched for as free function so you can add them without modifying library code.

Interesting idea. It reminds me of a systemic issue I have with D in general though on that front; the namespace of a user defined free function which is intended to be used UFCS style to do this sort of functionality expansion on types you don't control; there's always a problem with namespacing... I define the symbol somewhere, but there's no way to associate the import path with the original symbol. How would you find it? Normally the calling code is unable to have explicit imports for the helper functions... I imagine a similar challenge in the debugger, and I wonder if a creative solution for the debugger might also inform a similar solution for use in regular code...

I haven't tried anything yet, but it would be good if you can provide examples so I don't have to guess your use case.

Literally just a std.typecons.Tuple; it always shows as {} for me... no members, no expand.
I wonder if the symbol names for the members that the lib assigns look like internal names and are hidden in the same way you describe above. I think it might use underscores for unnamed members...

@rainers
Copy link
Member

rainers commented Dec 8, 2024

Maybe anything starting with __param should not be hidden.

How would you find it?

Indeed, not so obvious, but there is no module scope in the debug info to begin with, just mangling. I guess it has to be a global symbol search disregarding module name and return type. The good thing would be that it should also work with LDC which does not emit debug info for methods of a struct.

Literally just a std.typecons.Tuple; it always shows as {} for me... no members, no expand.

I tried that. Unfortunately, dmd doesn't emit any debug information about fields of a tuple, just a couple of methods. It works with LDC. There is even an option "recombine tuples from compiler generated fields" in the Mago options, but that results in misplaced commas (just fixed that).

@rainers
Copy link
Member

rainers commented Dec 14, 2024

The new version https://github.com/dlang/visuald/releases/tag/v1.4.0-rc4 now doesn't hide __param-symbols as compiler generated symbols.

It also supports free __debug functions as in

string __debugOverview(ref const String s)
{
    return s._s;
}

auto __debugOverview(ref Tuple!(int,int,int) tpl)
{
    struct S { int a, b, c; }
    return new S(tpl[0], tpl[1], tpl[2] );
}

auto __debugExpanded(ref Tuple!(int,int,int) tpl)
{
    return __debugOverview(tpl);
}

which can also be used as a workaround for the missing tuple debug info. Unfortunately returning larger structs directly doesn't work yet. You need explicite instantiations for the used tuple-types, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants