Brice

> The unit test `chainstate::stacks::db::transactions::test::test_checkerrors_at_runtime` is expected to fail with this change, because what used to trigger a runtime check error is now legal: > > ```clar > (use-trait trait...

Is there another runtime check error that I should replace this trait issue with in those unit tests, or should I remove them?

> Hey @obycode, is this ready for review? Sorry I didn't get a chance to ask at the blockchain call this week. Yes. The remaining todo item I have is...

> ```clar > (define-public (send-many (data (list 10 {amount: uint, sender: principal, recipient: principal})) (token )) > (ok (map my-iter data (list token token token token token token token token...

> I would say that one should fail with IfArmsMustMatch, even if the traits are compatible. If you need to do something like that, you can first cast the superclass...

Thanks for those examples @kantai. I added them to the type_checker tests in bb84402ec.

I reviewed the unit test `chainstate::stacks::tests::block_construction::test_is_tx_problematic` and found that there was actually a bug causing it to fail. That is now resolved so the case works as it did before...

I can't reproduce [this failure](https://github.com/stacks-network/stacks-blockchain/runs/8270925163?check_suite_focus=true) with `cargo fmt`. 🤔

The latest batch of changes added a new type to differentiate principal literals, which are callable, from principal values, which are not. This new type is merged with the type...

I realized that the type-checker allows the transitive trait issue that we discussed, but execution of this type of contract fails. I will add the appropriate tests to ensure the...