UnsupportedConstituents error is not helpful

[lovesegfault]

Consider the following script, to be applied to kernel 6.1:

load_kconfig_unchecked(kernel_dir .. "/arch/x86/configs/x86_64_defconfig")
DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT:satisfy { y, recursive = true }

It fails with this error:

linux-config>  Initialized bridge [kernel 6.1.13, 17205 symbols] in 756.85ms
linux-config>      Loading config (/nix/store/bcy6jr6clfwx2viph2zr7dxdyychrmls-linux-6.1.13-autokernel.toml) [autokernel 2.0.2]
linux-config>     Applying configuration (/nix/store/bcy6jr6clfwx2viph2zr7dxdyychrmls-linux-6.1.13-autokernel.toml)
linux-config>     Applying script (/nix/store/xp8xhhs98j6ir1y8cqyvhcddlbkhrlnl-linux-6.1.13-autokernel.lua)
linux-config> error: failed to assign symbol DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT to Tristate(Yes) at this location...
linux-config>   --> /nix/store/xp8xhhs98j6ir1y8cqyvhcddlbkhrlnl-linux-6.1.13-autokernel.lua:2
linux-config>    |
linux-config>  2 | DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT:satisfy { y, recursive = true }
linux-config>    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hint: this did not change the previous value Boolean(false)
linux-config>    |
linux-config>    = note: cannot suggest solution because automatic dependency resolution failed (UnsupportedConstituents)
linux-config> error: aborting due to 1 previous errors

This, unfortunately, is extremely hard to debug, since no further information on which constituents are unsupported is given.

It'd be great if it would at least provide some information regarding where in the resolution process it encountered the issue.

[oddlama]

True, that's not helpful. I've added a little more information for these cases, and I'm working on adding readable names (done). In this particular case you seem to be running into a less-than expression somewhere in the dependency tree. Comparisons are rare and unfortunately kind of impossible to solve automatically compared to boolean algebra, which is why they are currently unsupported. Due to the nature of these symbols there just is no heuristic that I could use to determine a good value since they often include hidden implications (imagine SOME_ALIGNMENT > 0) that we cannot gain information about in code.

It probably would be a good idea to parse them anyhow and just refuse solving them if they are unmet. That way it would at least be possible to set them manually before calling satisfy. I'll look into it tomorrow.

[oddlama]

Expressions can now be evaluated if they contain < <= > or >= with integer compatible symbols. The satisfier cannot automatically resolve these, but usually they are static assertions for e.g. compiler versions that shouldn't need to be changed anyway. Your original expression should work without changes now. :)