Chore/add custom error to clarity types

[jacinta-stacks]

This basically is ripping out VmExecutionError from clarity-types as well by introducing this error layer.

Closes #6731
Also closes #6730

[codecov]

Codecov Report

❌ Patch coverage is 70.41930% with 515 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.88%. Comparing base (4f535d8) to head (23c8c6b).
⚠️ Report is 48 commits behind head on develop.

Files with missing lines	Patch %	Lines
stackslib/src/chainstate/nakamoto/signer_set.rs	33.90%	115 Missing ⚠️
clarity-types/src/errors/analysis.rs	33.69%	61 Missing ⚠️
clarity-types/src/types/mod.rs	81.03%	44 Missing ⚠️
...ackslib/src/chainstate/nakamoto/coordinator/mod.rs	46.42%	30 Missing ⚠️
...y/src/vm/analysis/type_checker/v2_1/natives/mod.rs	36.58%	26 Missing ⚠️
clarity/src/vm/errors.rs	75.00%	24 Missing ⚠️
clarity/src/vm/functions/sequences.rs	65.67%	23 Missing ⚠️
clarity-types/src/types/signatures.rs	79.74%	16 Missing ⚠️
stackslib/src/chainstate/stacks/boot/mod.rs	34.78%	15 Missing ⚠️
.../src/vm/analysis/type_checker/v2_05/natives/mod.rs	33.33%	12 Missing ⚠️
... and 33 more

❌ Your project status has failed because the head coverage (72.88%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #6751      +/-   ##
===========================================
- Coverage    77.77%   72.88%   -4.90%     
===========================================
  Files          585      586       +1     
  Lines       361916   362349     +433     
===========================================
- Hits        281498   264084   -17414     
- Misses       80418    98265   +17847     

Files with missing lines	Coverage Δ
clarity-types/src/errors/mod.rs	33.33% <ø> (-42.23%)	⬇️
clarity-types/src/lib.rs	100.00% <ø> (ø)
clarity-types/src/representations.rs	85.49% <ø> (ø)
clarity-types/src/tests/representations.rs	75.00% <ø> (ø)
clarity-types/src/tests/types/serialization.rs	94.48% <100.00%> (-3.83%)	⬇️
clarity/src/vm/analysis/arithmetic_checker/mod.rs	92.48% <ø> (ø)
...larity/src/vm/analysis/arithmetic_checker/tests.rs	98.51% <ø> (ø)
clarity/src/vm/analysis/read_only_checker/mod.rs	86.64% <100.00%> (-1.53%)	⬇️
clarity/src/vm/analysis/read_only_checker/tests.rs	100.00% <ø> (ø)
clarity/src/vm/analysis/trait_checker/mod.rs	100.00% <ø> (ø)
... and 111 more

... and 206 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4f535d8...23c8c6b. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[federico-stacks]

Did a first pass. In the meantime, I’m sharing some thoughts

[brice-stacks]

I left a couple of comments, but before going further, I think I'm having trouble seeing the overall goal of all of this.

[jacinta-stacks]

I left a couple of comments, but before going further, I think I'm having trouble seeing the overall goal of all of this.

Essentially we are trying to pry apart unnecessary coupling between underlying clarity type creation/serialization/deserialization etc from static checks and vm executions as these functions are used throughout the code base where no vm is even required and we are not actually performing static checks.

This is basically the first step in enabling easier refactoring. If clarity-types returns CheckErrorKind, we've coupled the lowest layer to the VM/checker layer. That creates dependency inversion and makes refactors brutal.

I do think there is currently a lot of redundancy but this is required until we can pull it all apart properly. Additionally, you can get better error messages/types at the lower level that then are mapped to whatever the caller cares about. Sorry if I am not explaining this well.

EDIT: Here is a PR that builds on top of it that enables me to rip out the RuntimeError::TypeParseError and RuntimeError::ASTError more easily as a result: jacinta-stacks#1

[francesco-stacks]

Still going through the review, but posting some pointers for now.

Also, this refactoring would allow to move back all the errors (VmInternal, ClarityError, CheckError*, Parse, etc) in the clarity crate and just keep this new error type in clarity-types. I believe it will be a lot easier to reason about it, expecially regarding the idea that all other types are VM related, and not about the usage of the basis clarity types.

[francesco-stacks]

LGTM!

[federico-stacks]

lgmt!

Before final approval, are we waiting for block validation on this branch to rule out any regressions?

[jacinta-stacks]

lgmt!

Before final approval, are we waiting for block validation on this branch to rule out any regressions?

Yes! @wileyj has been running that on my behalf (EDIT: got green light from Jesse!). I also would like approval from @aaronb-stacks.

[aaronb-stacks]

This LGTM -- just a couple of comments.

[francesco-stacks]

Almost there! There are some unit tests failing.