-
Notifications
You must be signed in to change notification settings - Fork 700
Fix/bad syntax binding error variants #6343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/bad syntax binding error variants #6343
Conversation
… formatting code) to specialize CheckErrors::BadSyntaxBinding. Also, remove tuple-specific bad syntax binding errors since they are now captured by BadSyntaxBinding
…e-bindings, report the specific kind of error instead of the generic BadSyntaxBinding
…type-check a list of (name, value) pairs
…kind of binding being checked so an error will result in a meaningful message
…SyntaxBinding(..)
…ype-check being performed so error messages can reflect it
… to now check for the specific variant of BadSyntaxBinding. Also, add comprehensive checks for each variant of BadSyntaxBinding, as well as test to verify that error messages do not grow unbound with the type's nesting depth
…nding error and the specific context in which it occurs
…uple being checked
…reporting, and consolidate Display implementation for SymbolicExpression and SymbolicExpressionType
…and update tests to expect when BadSyntaxBinding wraps another CheckErrors variant
…g expecting it to wrap an inner CheckErrors variant which lead to a bad binding
…xBindingError::BadTypeSignature(..) ..), instead of BadSyntaxExpectedListOfPairs, so the caller has a better idea about what is structurally deficient about the binding or type signature
…ntax-binding-error-variants
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #6343 +/- ##
===========================================
+ Coverage 75.26% 80.11% +4.85%
===========================================
Files 555 555
Lines 351247 351471 +224
===========================================
+ Hits 264353 281598 +17245
+ Misses 86894 69873 -17021
... and 233 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I just noted a couple of import clippy warnings that need to be fixed.
…ntax-binding-error-variants
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have two high-level pieces of feedback on the new error type:
-
The new error struct shouldn't keep a copy of the expression. Either the struct and the binding handlers should be refactored so that this can be avoided (making sure to pass the correct expression to the
CheckError
struct). Another option is that rather than wrap theSyntaxBindingError
into aCheckErrors
variant, we do something like make each of theSyntaxBindingError
variants into a newCheckErrors
variant, and then defineFrom<SyntaxBindingError> for CheckError
which pulls the expression out of theSyntaxBindingError
(so rather than wrapping a SyntaxBindingError, we're converting from a SyntaxBindingError). I'm a little agnostic between those, but I definitely think that using theCheckError
's diagnostic/expression field is the right thing to do. -
BadTypeSignature
should be dropped, and the underlying error should just be returned. I think the pain of returning the underlying error is that previously theCheckError
expression that is constructed used the whole binding as the expression (e.g., the tuple type definition) rather than the just the offending expression. So instead, we should just make sure that we're setting the offending expression on the returned CheckError. This will probably involve some careful type handling in theparse_name_type_pairs
function, but it certainly seems doable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…_type_pairs() return Result<_, E> where E: for<'a> From<(CheckErrors, &'a SymbolicExpression)> so these functions can be used in both analysis and runtime contexts with the appropriate error types (this patch also adds conversions for them)
…b.com/jcnelson/stacks-core into fix/bad-syntax-binding-error-variants
ed22100
Description
This PR improves the expressiveness of
CheckErrors::BadSyntaxBinding
and some related binding errors to indicate both the kind of binding considered, as well as the specific structural deficiency. Specifically, it differentiates between faulty let-bindings, function definitions, and tuple constructors, and it treats all instance of invalid type signatures found in top-level definitions asCheckErrors::BadSyntaxBinding
while reporting the innerCheckErrors
error message and innermost faulty binding in the signature.For example, in
develop
today, these errors are reported.In this PR, these same errors are as follows:
Right now, this PR does not touch
CheckErrors::BadMayTypeDefinition
, but I'm happy to add that as well.Applicable issues
Additional info (benefits, drawbacks, caveats)
Looking at where the errors were used, it does not appear that any changes are consensus critical. I could not find any place in the codebase where the caller matches on a
CheckErrors
value affected by this PR.Checklist
docs/rpc/openapi.yaml
andrpc-endpoints.md
for v2 endpoints,event-dispatcher.md
for new events)clarity-benchmarking
repobitcoin-tests.yml