Assertion due to unprocessed type info

[oleid]

I just tried HEAD to check out the lastest changes and noticed I hit a recently introduced assert in typereader.rs.
Aparrently, there are still wip_items left. A quick hack

diff --git a/src/dwarf/typereader.rs b/src/dwarf/typereader.rs
index 3adfcf0..3f86923 100644
--- a/src/dwarf/typereader.rs
+++ b/src/dwarf/typereader.rs
@@ -45,6 +45,11 @@ impl<'elffile> DebugDataReader<'elffile> {
                         }
                         typereader_data.wip_items.clear();
                     }
+                    if !typereader_data.wip_items.is_empty()
+                    {
+                        println!("WARNING: Unprocessed type info, ignoring:\n{:?}", typereader_data.wip_items);
+                        typereader_data.wip_items.clear();
+                    }
                     assert_eq!(typereader_data.wip_items.len(), 0);
                 }
             }

yields:

WARNING: Unprocessed type info, ignoring:
[WipItemInfo { offset: 124267, name: Some("CAN_CONFIG"), tag: DwTag(22) }, WipItemInfo { offset: 124199, name: None, tag: DwTag(19) }, WipItemInfo { offset: 124340, name: None, tag: DwTag(15) }]
WARNING: Unprocessed type info, ignoring:
[WipItemInfo { offset: 124283, name: Some("CAN_MB_CONFIG"), tag: DwTag(22) }, WipItemInfo { offset: 124069, name: None, tag: DwTag(19) }, WipItemInfo { offset: 124340, name: None, tag: DwTag(15) }]
WARNING: Unprocessed type info, ignoring:
[WipItemInfo { offset: 498045, name: None, tag: DwTag(1) }, WipItemInfo { offset: 492863, name: Some("lwip_socket_multicast_pair"), tag: DwTag(19) }, WipItemInfo { offset: 497538, name: None, tag: DwTag(15) }, WipItemInfo { offset: 495412, name: Some("lwip_sock"), tag: DwTag(19) }, WipItemInfo { offset: 497550, name: None, tag: DwTag(15) }, WipItemInfo { offset: 493009, name: Some("netconn"), tag: DwTag(19) }]

I'm not really sure what's the issue here or if the items are required for something.

[DanielT]

Yes, I've made some fairly large changes to the typereader. It tries to extract much more info than it used to, in order to be able to support creating / updating of INSTANCEs and TYPEDEF_STRUCTUREs.

Reading types is a recursive procedure, since all member types are needed in order to fully specify a structure type, but those types might not be known yet. What you see here is that reading some types failed several recursion levels deep, and the information about the entire chain was lost.

Honestly, I had hoped that I had finally managed to make type reading robust enough that no information would be lost.
That's why this assertion exists.
Since that was clearly too ambitious, I will improve the error output for this case instead.

[oleid]

No more issue since #29, so this can be closed