ISLE: add support for multi-extractors and multi-constructors.

[cfallin]

This support allows for rules that process multiple matching values per extractor call on the left-hand side, and as a result, can produce multiple values from the constructor whose body they define.

This is useful in situations where we are matching on an input data structure that can have multiple "nodes" for a given value or ID, for example in an e-graph.

This is the first piece of the implementation of bytecodealliance/rfcs#27.

[github-actions]

Subscribe to Label Action

cc @cfallin, @fitzgen

This issue or pull request has been labeled: "cranelift", "isle"

Thus the following users have been cc'd because of the following labels:

• cfallin: isle
• fitzgen: isle

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[cfallin]

Updated, thanks!

[jameysharp]

I still need to read this more carefully, but I think it looks good.

One question so far: what's the intended difference between returning Some with an empty iterator, versus returning None? Put another way, what would we lose if we remove the Option wrapper from those return types? I understand the use of Option for fallible non-multi extractors, but I'm not sure how that extends here. I'd prefer to just use an empty iterator to indicate that the extractor failed, if that's not too much trouble, because otherwise the types appear to permit two ways of encoding the same situation.

I don't see any documentation for how someone writing an external multi-extractor should implement the auto-generated traits. I don't think that's strictly necessary before merging this, but if that documentation existed then I would look for the answer to the above question there.

[cfallin]

One question so far: what's the intended difference between returning Some with an empty iterator, versus returning None?

That's a good question. Functionally there is no difference, and the main reason is just to manage complexity: otherwise we have a special case wherever we have a match failure in that we have to invent an empty iterator rather than return None. If it were one code-generator site then maybe that's fine, but we also use the ? operator everywhere and I didn't want to work out how to get auto-conversions going with that. It's simpler to stick to the invariant that all constructors live in the Option monad and let the Try magic do its thing.

[jameysharp]

I asked Chris to show me a diff of the generated code for existing uses of ISLE. We verified that the only difference was additional types and traits related to ContextIter. As a result I'm convinced that this is safe to merge as-is. I haven't fully understood the multi-extractors and multi-constructors, but since we don't use any of those yet, we can fix any issues that come up when we start trying to use them, instead of worrying about them now.