Hello!
First of all, thank you for all your work on Xsmith. It's an incredible tool!
I've run into an issue while trying to create a fuzzer for a small, Haskell-like language. It appears as though the version of xsmith available via `raco` does not contain some of the canned components found in the Xsmith repository, so I opted to define the components myself, drawing heavily on LambdaSingleWithExpression. I also defined a VariableReference equivalent, and basic arithmetic. However, running Xsmith, I was consistently met with an error like the following:
xsmith: internal error -- no destinations for lift from: XsmithAstHoleExpression, type: #<number>, depth: 2
I run into a similar issue when using purely canned components such as LambdaWithExpression and VariableReference. That is what makes me suspect that this is a bug.
From what I understand, whenever a reference node is created, Xsmith attempts to fill it with a visible variable of the same type, and if none is found, it attempts to "lift" the new reference, adding it to an existing definition. Lambda functions cannot be "lifted" to (since doing so would change the function's type); this leaves no constructs in my small language to serve as lift targets. However, I don't think this should be an error. The debug log mentions concretizing various "arg"s (formal parameters of the Lambda) to be of type #<number>:
Concretizing binding def1. Type: #<type-variable #f>, concretized to: #<number>
Concretizing binding arg2. Type: #<type-variable #f>, concretized to: #<number>
This leads me to believe that they are suitable to fill a reference of type #<number> (as reported in the internal error). However, this never occurs, and I get "no destinations to lift from" as soon as Xsmith picks a reference. This seems to make it nearly impossible to define a language in which lambda functions are the only source of binding. My suspicion that this is a bug is further corroborated by the fact that the lambda functions generated by the "Canned Components" example from the manual overwhelmingly ignore their arguments. Out of 20 lambda functions generated from 4 runs of the fuzzer, only 2 used their argument, while the others created and lifted a new reference.
I hope I'm not missing something obvious.
Thank you in advance,
Daniel