Stream: git-wasmtime

Topic: wasmtime / issue #11971 ISLE: debugging feature to emit l...

Wasmtime GitHub notifications bot (Nov 03 2025 at 17:04):

fitzgen opened issue #11971:

To assist with debugging ISLE (e.g. you expect a rule to match but it doesn't), the isle crate should have an option to emit log macro invocations in the generated code.

I'm imagining we would emit the following logs, or something similar:

• log::debug!(...) at the start of a constructor, logging which constructor we are executing. (Ideally, we would also log the arguments given, but that would require that we know that the arguments implement Debug, which I don't think we do? Failing that, if we wanted to get real fancy, we could do the thing where you approximate specialization by making impls for &T, &&T, etc...)

• Each predicate we test as part of a term's rules' LHSes would have an associated log::trace!(...) that details which predicate is executing and then whether it matched or not.

• In each rule's RHS we would log::debug!(...) which rule we end up executing.

• Possibly, if none of a term's rules match, we log that fact as well. Not sure if we have erased this information by the time we emit code or not though, so it might not be possible.

To make this even more readable when debugging, it would be nice if we kept a thread-local or something containing the ISLE stack depth and indented our logs by that amount, so that you could see which constructor invocations were nested within others.

Wasmtime GitHub notifications bot (Nov 03 2025 at 17:04):

fitzgen added the isle label to Issue #11971.

Wasmtime GitHub notifications bot (Nov 03 2025 at 17:05):

github-actions[bot] commented on issue #11971:

Subscribe to Label Action

cc @cfallin, @fitzgen

<details>
This issue or pull request has been labeled: "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 <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Nov 03 2025 at 17:08):

cfallin commented on issue #11971:

Thanks for writing this up! I agree we should do this; also it might be a good first issue (I'll add the tag). One particular thought on

but that would require that we know that the arguments implement Debug, which I don't think we do?

I don't see a problem with adding this requirement if we don't have it yet; we control the main/only user of ISLE, the set of types that flow across the Rust/ISLE boundary are fairly small, are mostly little newtype wrappers, and even the big ones (BoxCallInfo as a Box of CallInfo returned from a helper) should be printable.

Wasmtime GitHub notifications bot (Nov 03 2025 at 17:08):

cfallin added the good first issue label to Issue #11971.

Wasmtime GitHub notifications bot (Nov 03 2025 at 19:13):

fitzgen edited issue #11971:

To assist with debugging ISLE (e.g. you expect a rule to match but it doesn't), the isle crate should have an option to emit log macro invocations in the generated code.

I'm imagining we would emit the following logs, or something similar:

• log::debug!(...) at the start of a constructor, logging which constructor we are executing. (Ideally, we would also log the arguments given, but that would require that we know that the arguments implement Debug, which I don't think we do? Failing that, if we wanted to get real fancy, we could do the thing where you approximate specialization by making impls for &T, &&T, etc...)

• Each predicate we test as part of a term's rules' LHSes would have an associated log::trace!(...) that details which predicate is executing and then whether it matched or not.

• In each rule's RHS we would log::debug!(...) which rule we end up executing.

• Possibly, if none of a term's rules match, we log that fact as well. Not sure if we have erased this information by the time we emit code or not though, so it might not be possible.

To make this even more readable when debugging, it would be nice if we kept a thread-local or something containing the ISLE stack depth and indented our logs by that amount, so that you could see which constructor invocations were nested within others.

Anyways, once we had this knob in the ISLE compiler, we should add a cargo feature to cranelift-codegen which enables/disables it. (Or maybe we just reuse the existing trace-log feature?)

Wasmtime GitHub notifications bot (Nov 06 2025 at 17:32):

alexcrichton added the cranelift:E-compiler-easy label to Issue #11971.

Wasmtime GitHub notifications bot (Nov 08 2025 at 11:27):

bahbah94 commented on issue #11971:

I can have a crack at this issue, will be going through the source code, any particular source file that is of interest, i would be happy to look into( I'm new to cranelift or compilers in general).

Wasmtime GitHub notifications bot (Nov 13 2025 at 19:14):

cfallin commented on issue #11971:

@bahbah94 you'll want to look at the codegen from the ISLE-to-Rust compiler in this file. That generates Rust source code that is then compiled as part of the main Cranelift crate.

Last updated: Dec 06 2025 at 07:03 UTC