Chore/add custom error to clarity types

[jacinta-stacks]

I have added a bunch of comments that I will need to rip out before merging this. Mostly around where I am changing what was previously an "Expect" into a Nonexpect error. Mostly cause they prob shouldn't ever happen/I don't know why they would actually invalidate a block. I also added an ExpectAcceptable and ExpectRejectable type.

Feedback would be good.

[codecov]

Codecov Report

❌ Patch coverage is 71.54538% with 348 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.42%. Comparing base (c9003aa) to head (8f25aad).

Files with missing lines	Patch %	Lines
clarity-types/src/types/mod.rs	74.73%	72 Missing ⚠️
clarity-types/src/errors/analysis.rs	34.44%	59 Missing ⚠️
stackslib/src/chainstate/nakamoto/signer_set.rs	55.68%	39 Missing ⚠️
...ackslib/src/chainstate/nakamoto/coordinator/mod.rs	47.82%	24 Missing ⚠️
...y/src/vm/analysis/type_checker/v2_1/natives/mod.rs	25.80%	23 Missing ⚠️
clarity-types/src/types/signatures.rs	83.13%	14 Missing ⚠️
clarity/src/vm/analysis/type_checker/v2_1/mod.rs	26.66%	11 Missing ⚠️
.../src/vm/analysis/type_checker/v2_05/natives/mod.rs	28.57%	10 Missing ⚠️
clarity/src/vm/functions/sequences.rs	78.72%	10 Missing ⚠️
clarity/src/vm/analysis/type_checker/v2_05/mod.rs	18.18%	9 Missing ⚠️
... and 20 more

❌ Your project check has failed because the head coverage (77.42%) 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.90%   77.42%   -0.48%     
===========================================
  Files          580      580              
  Lines       361187   361490     +303     
===========================================
- Hits        281374   279877    -1497     
- Misses       79813    81613    +1800     

Files with missing lines	Coverage Δ
clarity-types/src/errors/mod.rs	76.34% <100.00%> (+0.78%)	⬆️
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/mod.rs	97.07% <100.00%> (+0.02%)	⬆️
clarity-types/src/tests/types/serialization.rs	98.27% <100.00%> (-0.04%)	⬇️
clarity-types/src/tests/types/signatures.rs	99.12% <100.00%> (ø)
...rc/vm/analysis/type_checker/v2_1/natives/assets.rs	98.36% <100.00%> (ø)
...lysis/type_checker/v2_1/natives/post_conditions.rs	97.27% <ø> (ø)
clarity/src/vm/contexts.rs	92.24% <100.00%> (+0.01%)	⬆️
... and 50 more

... and 91 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 c9003aa...8f25aad. 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

[federico-stacks]

Good point! I don’t have a definitive answer. On one hand, I’d prefer to eliminate the expect calls; on the other hand, they do help break the "error chain".

[federico-stacks]

Just sharing some reasoning on possibly changing admits_type_v2_0 and admits_type_v2_1 to return a plain bool instead of Result<bool, ClarityTypeError>:

• For both admits_type_v2_0 and admits_type_v2_1, it looks feasible to return only bool since they don’t meaningfully use the error channel.
• The only blocker comes from the top-level admits_type, which currently returns
  StacksEpochId::Epoch10 => Err(ClarityTypeError::UnsupportedEpoch(*epoch))

If we could treat that case as StacksEpochId::Epoch10 => false instead, then all admits_type* methods could avoid returning ClarityTypeError entirely.

[jacinta-stacks]

I don't think they can do this. I had tried before and admits_type_v2_0 both rely on recognizing the type otherwise they return Err(ClarityTypeError::CouldNotDetermineType) which I think it important? I mean maybe at that point you can ALSO just return false? However, I am not 100 percent sure at this point and think it should be a sep ticket to look into the repercussions of treating any failure to determine the type as false.

[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.

[brice-stacks]

I'm finding all of these repeated errors confusing. It feels like there should instead be a StaticCheckErrorKind (and others) that contains a ClarityTypeError instead of replicating all of these.

[jacinta-stacks]

I am currently avoiding changing any of the StaticCheckErrorKind or CheckErrorKind. The idea is that underlying errors should be mapped only to the relevant ones in the *CheckErrorKind types. i.e. granularity can be lost as you go up through the chain and we are wanting as flat of a map as possible in the CheckError types. But perhaps this is wrong and we should just hold a TypeError but I am not 100% confident that these typerrors change their importance depending on WHGERE they are called. i.e. check error kinds may treat the same error type as fatal in some isntances vs not. Would do this sort of change in a sep PR.

[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.