Change:
tuple_type, &tuple_name[..], unique_type_id, <del> NO_SCOPE_METADATA); </del> <ins> containing_scope); </ins> create_and_register_recursive_type_forward_declaration( cx,

Discussion:
Some idea as
Here's the broken object file.
is this something that's easy for ddbug to check for and give more information about?
Maybe, but I don't understand what the problem is and what needs to be checked. The type of 0x001b2d2f is 0x001b2d3d, and I don't know why it claims 0x001b2d3d is a forward declaration since its members are defined too.
So the crash doesn't happen with rust-lldb, so this probably pretty low to fix. Otherwise it seems like the next steps would be to figure out what's going on in lldb's DWARFFastParserClang and why it's sad about our info.
I have this occurring with rust-lldb. Sample code: And I'm stepping into the call. I have rexpect installed locally via: and am running: I'm on macOS 10.14.2 with just installed cargo and rust ().
It seems like has resurfaced. From what I understand this is causing some issues for WebRender devs.
I'm going to look into this asap. Thanks for the test case, that should be very helpful!
I can reproduce this on macOS and Linux. On Linux I can reproduce with a recent debug build of LLDB.
maybe we should make this . At least it's what I'll be working on until it's resolved.
I've been able to make some progress here. I was not able to pinpoint why exactly LLDB fails to load the type info for fields in question but for the test cases I had, the bug occurred only when LLDB tries to get the type information of fields in a closure environment. I tried debugging further but with my limited understanding of LLDB's codebase makes this very time-consuming. So, for the time being I propose to implement a workaround: If we make mark closure environment structs and their fields with then LLDB does not hit the problematic code paths. Marking those fields as artificial is the right thing to do here anyway (we already do it for things like fields of slices). It's unfortunate that we don't know the exact problem in LLDB but the workaround would not be a hack. In my local testing this did not break any debuginfo tests for either LLDB or GDB.
I may be able to look into the LLDB side further.

Do you have a simple testcase I can use? I wasn't able to reproduce with the testcase given earlier. At a guess, the problem may be because we use the same name () for multiple types.
That would be awesome, Are you familiar with compiling Firefox? Then getting a test case is straightforward. It's also somewhat lengthy initially so bear with me Get a recent clone of Firefox, e.g. from Make sure you've get an up-to-date build environment by running in the root dir of the FF checkout. Place the following file in the root dir of the checkout: Run in the root directory of your FF checkout. Depending your machine this will take between 5 and 50 minutes Run in the root directory of your FF checkout. This starts a debug instance of the browser. Type into the address bar, look for the option and make sure it is set to . If you needed to change it, close the browser and run again. The test browser should have remembered the setting. If you are on Linux, find out the process ID of the process named , if you are on macOS, find out the PID of the main FF process. Start your version of LLDB and run Once LLDB has successfully stopped FF, set a breakpoint via Run in LLDB and focus the FF window. The breakpoint should be hit immediately. Now type into LLDB. This should trigger the problematic code path and make LLDB crash. For me, the above repro worked on Fedora 30 as well as an up-to-date macOS. It also worked with the stock macOS LLDB version, LLDB 8 on Fedora and a self-compiled LLDB from a recent LLVM master. Maybe yeah. Unfortunately, LLDB crashed on me while debugging itself and seemed to get stuck indefinitely after executing in LLDB.
Thanks for the instructions, Here's a reduced testcase: (in lldb: , , ).
Hex editing the DWARF to change the names of the closure types stops the error from happening.
Very interesting! Generating some kind of unique name for the closure types shouldn't be too hard.
Alright, so I would suggest fixing this issue by doing both: closure environment structs and their fields with , and a unique type name for closure environment structs. The same should probably done for generators (I have not really looked at those yet).

Implementing item (1) should be straightforward: Go into and make closure types and their fields get applied. The debuginfo for closure types is created here: ... and implementing this will mean that needs to grow a parameter. The rest is just threading the right flags value through the various function calls. Closure fields are created here (because the compiler treats them as tuple fields): Similar to the case above, should probably be parameterized with a field which can then be used to make closure fields . For examples, one can also look for other occurrences of in the same file. Implementing item (2), i.e. generating a unique type name for closures, is even simpler: Debuginfo type names are generated in , and for closures specifically the name is generated here: The first field of the we have available here is the of the closure, which gives us access to pretty much anything we can know about it. A very simple way of making the type name unique would be to append the of the closure to it, e.g. . The for a given can very cheaply be obtained via . One could also find a more human-readable unique name for closure types (e.g. by using the instead of the ) but that would be more costly and take up more space, so I think for now the is a good option. I'm gonna tag this issue as and in case somebody wants to take a stab at implementing the suggested fix. I'm happy to help out with any questions.
Further reduced: In lldb: , , . The requirements are to have the struct for one closure included as a member of the struct for another closure, and then get lldb to print that struct. I'll take a look at implementing the fix.
Thanks, This should also make for a good regression test.
Should I be using for the names? That's 32 bytes, which seems a bit larger than needed. Probably not something to do right now, but maybe we should move these types inside the functions where they are defined, and then use a simple disambiguation index (are we doing something like this for mangling closure symbols?). This would be similar to using , except that we don't need to repeat the path because the location of the type means it simply inherits the path of the function.
Yes, I also think that we don't need that many characters for disambiguation.

I'd probably do something like: This should result in ~11 disambiguation chars which seems fine. Do DWARF & LLVM allow for type DIEs inside of function DIEs? What would be the implications? I can't remember if we already do something like this (we definitely use namespaces though).
I haven't checked clang, but here's some output from gcc which does that:
This whole thread had me confused because I just assumed we were using def-paths (like symbol names do, and we know those are unambiguous), but I thought maybe it was some subtlety everyone else was aware of. Thanks for asking this "out loud", everything's clear now! I wonder if there are other bugs/complications arising from debuginfo not (fully) relying on the disambiguating information that everything else is based on.
You should be able to create similar situations to closures via this: This should create two structs with the same def-path except for the disambiguator on the last component (since blocks don't introduce their own def-path components).
Well, I don't think DWARF actually demands that types have different names. Each DIE has some kind of ID and the attribute is actually optional.
I remember now: We are building a parallel tree of s and put the types into those, because at the time (5 years ago?) GDB wasn't able to handle types inside of functions. Here's what this looks like: DWARF It would be great to get rid of that hack
Ok, but the closure types are all being put under the . So we should at least move them into that namespace with the rest of the types, but yes getting rid of the parallel tree would be good too. Not sure if this will cause problems, but one possible difference from other languages is that these types are visible outside the function by returning .
Pretty sure you can get the same in C++ with .
I'm pretty sure would give you the expected namespace. You can find many examples of how this is used in . Right now we seem to re-use the tuple metadata infrastructure for closures, which is why they all end up in the top-level scope.