Segmentation fault inferring result of xml.Element.select() when running as a .dac file

[ShadauxCat]

This is not an xml bug, it's just easily reproduced using the xml module.

load xml

var doc = xml.parse(
@[]
<root>
    <children>
        <child>
        </child>
    </children>
</root>
@[]);
var root = doc.root;

var childrenElem = root.find("children");
var children = childrenElem.select("child");
#Anything below here doesn't matter...

This runs fine with dao myFile.dao, but if run as dao -c myFile.dao followed by dao myFile.dac, it will segfault on the last line. It does not crash if I change that line to the following:

var children : list<xml.Element> = childrenElem.select("child");

When compiling this using dao -c myFile.dao I see the following error:

ERROR: Unencoded cdata type (name = Element)!

This seems related as it goes away if I specify the variable type.

[daokoder]

Sorry for the delay. I finally start to have some time to work on Dao again:)

This bug was caused by the return type of find() which is a variant type of Element | none. This type is automatically casted to Element when used. The problem is that the cast operation is inserted during type inferencing, so the Element type is also got stored in the routine at this time. Since the type is inferred from find(), the bytecode encoder has no idea how to lookup this user-defined type directly, so it does not know how to represent this type in the bytecode file.

Initially, I tried to solve this problem by figuring out a way to directly lookup types that do not show up in the source code, but there seems to be no reasonable way. It made me wonder it might have been a bad design if the bytecode format has to encode inferred types that cannot be easily lookup. It seems the best way to fix this bug is to to fix the design. So what I did is to add a new VM instruction and make a couple of minor changes to avoid the need to encode inferred types.