Various cleanups, mostly around the compiler #828
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
Need to investigate why jj is not signing these commits. |
apoelstra
force-pushed
the
2025-05-compiler
branch
from
1959461 to
e228232
Compare
Member
Author
|
I had authored them with the wrong email address set. |
apoelstra
force-pushed
the
2025-05-compiler
branch
from
e228232 to
bae6bf5
Compare
tcharding
approved these changes
Jun 20, 2025
Member
|
Code review only, my ack has no weight in regards to semantic correctness of the changes. |
apoelstra
force-pushed
the
2025-05-compiler
branch
2 times, most recently
from
5dff64e to
c317cd7
Compare
Member
Author
|
cc @sanket1729 this one is a real PR, but just pinging you in case you missed it. |
This was an oversight in rust-bitcoin#815.
Generally we try not to add special-case logic for weird tools, but this is a a really simple change and I think that jujutsu is going to become pretty popular among rust-bitcoin developers. This is some repeated code which looks like it should be factored out into a utility function, but we can't really do that because we need to figure out the workspace root before we can even locate utility functions.
We can cause panics in the compiler comparing OrdF64s which are NaN, which we can produce by parsing ors where every child has weight 0. Simply make it a parse error to have any zero-probability branches. In theory somebody might want an or where some fragments have positive probability and others are 0, indicating "maximally pessimize these". But it has never occurred to me to do this, and it's easy to simulate this by using 100s and 1s, say.
In the compiler we have a function which inserts the "cast closure" of an expression. It accepts the expression as a candidate as well as a large list of cast-wrapped variants of the expression. For each candidate it rejects it if it is consensus-invalid or has malleable satisfactions. In the original compiler (PR rust-bitcoin#29) it would decide whether an expression was malleable by checking ty.mall.non_malleable on the miniscript. It had the confusing comment "return malleable types directly" which I believe was supposed to mean "return early if the node is malleable". The comment also observes that "If a elem is malleable, all the casts to it are also going to be malleable" but the code doesn't actually use this fact anywhere. It always tries all the casts. But ok, whatever. Later in rust-bitcoin#97 (add context to Miniscript) we weakened the malleability check in a bizarre way -- now it checks that the node is malleable according to the type system AND that it is non-malleable according to the context system. That is, we whitelist or_i and d: as "acceptable malleability" in a legacy/bare context. This change, which was not commented on in the original PR, seems like it's just totally wrong. I suspect it was supposed to be an or: if the node is malleable according to the type system OR according to the contextual checks, then skip it. But I'm unsure. (The check is also wrong because the contextual check is wrong; see the last commit.) Anyway, after some fairly heavy fuzzing I was unable to find any instance where this check affects compiler output. I suspect that it's merely an optimization. So change it back to the stronger, simpler check and update the comment.
These can't be constfs but they're still useful.
This eliminates some expect()s and is plausibly faster.
…lerError The limitation that we have only binary and()s and or()s is really just a compiler limit; it's neither needed nor enforced when parsing policies, printing them, lifting them, etc etc. Maybe we _want_ to enforce this at the type level, but we don't now, and given that, these error variants are in the wrong place (and will get in the way of the refactors in the next commit).
apoelstra
force-pushed
the
2025-05-compiler
branch
from
c317cd7 to
bf10e45
Compare
Member
Author
|
Rebased. |
sanket1729
approved these changes
Jul 16, 2025
Member
sanket1729
left a comment
sanket1729
left a comment
There was a problem hiding this comment.
ACK bf10e45
Sorry for the delay. Interesting bug with 0 probabilities.
heap-coder
added a commit
to heap-coder/rust-miniscript
that referenced
this pull request
Sep 27, 2025
…nd the compiler
bf10e45a993f30b9b060a16885c563a7e966a802 compiler: pull non-binary argument errors from PolicyError into CompilerError (Andrew Poelstra)
3bc6c44e35b84a85f71cdf8abbd5567d8974c544 compiler: use Miniscript terminal constructors directly (Andrew Poelstra)
b8d8910abd7e4bafd0c9e69423ef912782d0dcc7 miniscript: add infallible multi() and multi_a() constructors (Andrew Poelstra)
fcbcf4e6e4dfc9a6b0eb862059d81faf3544805d compiler: revert malleability check to simpler version (Andrew Poelstra)
f98f263694951a3f3f1de5a2eae8fe0b57e96399 compiler: forbid fragment probabilities of 0 (Andrew Poelstra)
16b4d6044a791197bdee85bde537a7954f1e4d8a fuzz/generate-files: support jujutsu (Andrew Poelstra)
e0001462a185b63d9c1c4ea42222f14bcbce77d1 tr: cache TrSpendInfo when computing it (Andrew Poelstra)
2284858fb6b30619839e0833466059465694a602 tr: add `into_control_block` accessor to TrSpendInfoIterItem (Andrew Poelstra)
Pull request description:
This PR is a grab back of prepatory commits for larger changes. It includes a couple of followups to #815 in the first commits. Then it cleans up some error types and paths.
I don't believe anything in here will be tricky or controversial, though there are API breaks because of the cleaned up error types.
ACKs for top commit:
sanket1729:
ACK bf10e45a993f30b9b060a16885c563a7e966a802
Tree-SHA512: 8a6c9006fb6473187a2ba69f0311fc29756c5f99544e35ab499658910e8f82a10eff740a19634b5d0c6807c583b8cd79fdc9fbf8a59b78ab96d5b387759db2b7
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a grab back of prepatory commits for larger changes. It includes a couple of followups to #815 in the first commits. Then it cleans up some error types and paths.
I don't believe anything in here will be tricky or controversial, though there are API breaks because of the cleaned up error types.