Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Parse Error when input is larger than field #1169

Closed
porcuquine opened this issue Feb 23, 2024 · 1 comment
Closed

Parse Error when input is larger than field #1169

porcuquine opened this issue Feb 23, 2024 · 1 comment
Assignees
@johnchandlerburnham
Labels
bug Something isn't working

Comments

@porcuquine
Copy link
Contributor

Lurk appears to produce a parse error when presented with input that needs to be reduced. For example, the following should return 0:

commit: 2024-02-13 1d4d308e2bc12f5ab431ea210c0b722f9eb31825
Lurk REPL welcomes you.
user> -1
[1 iteration] => 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000000
user> 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000000
[1 iteration] => 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000000
user> 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000001
Read error: Syntax error: Parsing Error: ParseError { input: LocatedSpan { offset: 66, line: 1, fragment: "", extra: () }, expected: None, errors: [Nom(Tag)] }
user>
@porcuquine porcuquine added the bug Something isn't working label Feb 23, 2024
johnchandlerburnham added a commit that referenced this issue Feb 24, 2024
@johnchandlerburnham
new numeric parser, closes #609, #1161, #1169
2edc2ad 
- merges previous parse_num and parse_uint into a single parse_numeric
- removes bounds check on Num, so that parsing numbers larger than the
  field will modularly wrap
- corrects uint parsing so that we never accidentally parse uints as
  nums
- implements a placeholder syntax for i64 for parsing twos-complement
  numbers (i.e. -1i64 parses to u64::MAX). In future this syntax should
  parse to a new literal type
- add placeholder parsing for u8, u16, u32, u128, i8, i16, i32, i128
  literals so that we correctly error that these have yet to be
  implemented
- adds unit tests to ensure correctness of the above
github-merge-queue bot pushed a commit that referenced this issue Feb 25, 2024
@johnchandlerburnham
new numeric parser, closes #609, #1161, #1169 (#1171)
7e95ec4 
* new numeric parser, closes #609, #1161, #1169

- merges previous parse_num and parse_uint into a single parse_numeric
- removes bounds check on Num, so that parsing numbers larger than the
  field will modularly wrap
- corrects uint parsing so that we never accidentally parse uints as
  nums
- implements a placeholder syntax for i64 for parsing twos-complement
  numbers (i.e. -1i64 parses to u64::MAX). In future this syntax should
  parse to a new literal type
- add placeholder parsing for u8, u16, u32, u128, i8, i16, i32, i128
  literals so that we correctly error that these have yet to be
  implemented
- adds unit tests to ensure correctness of the above

* clippy

* clippy part II: revenge of the linter

* remove unused byte parsers and associated tests

* comment out printlns
@arthurpaulino
Copy link
Contributor

Closed by #1171

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@johnchandlerburnham johnchandlerburnham

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@porcuquine @arthurpaulino @johnchandlerburnham