### Before
```
x Flag u is mentioned twice in regular expression literal
,-[1:20]
1 | const a = /\2(.)/uuxig;
: ^
2 | debugger;
`----
x Unexpected flag x in regular expression literal
,-[1:21]
1 | const a = /\2(.)/uuxig;
: ^
2 | debugger;
`----
```
### After
```
x Flag u is mentioned twice in regular expression literal
,-[1:19]
1 | const a = /\2(.)/uuxig;
: ^
2 | debugger;
`----
x Unexpected flag x in regular expression literal
,-[1:20]
1 | const a = /\2(.)/uuxig;
: ^
2 | debugger;
`----
```
Closes#5177
While making this, I noticed an uncaught parse error for accessors: accessors cannot be optional. I'll add a fix for this in an up-stack PR.
Reverse `if` arms in 2 very commonly-called methods in `Source` so that "not at EOF" is the first branch. This will encourage compiler to treat EOF as the cold branch (which it should be, as we're almost never at EOF).
`Lexer::read_left_angle` was a series of disparate `next_ascii_byte_eq` and `peek_byte` calls. Convert it to a single match on `peek_byte`. This I think will remove a couple of bounds checks.
Optimize `Lexer::hex_digit`.
Rather than checking for `A-F` and `a-f` separately, can check for them both in one go. `b'A' | 32 == b'a'` (and same for all other alphabetic letters) so matching against `b | 32` allows checking for all matching letters, lower or upper case, in one operation.
Add `Lexer::consume_2_chars` to replace `lexer.consume_char(); lexer.consume_char();`. Mostly this is just neater code, but *may* also help compiler to elide bounds checks when it's preceded by `lexer.peek_2_bytes()`.
Iterating over `str.as_bytes()` produces `&u8`s. Dereference to `u8` in `for` statement. Should make no difference to generated assembly, purely making this change for neater code style.
Follow-on after #4304. Avoid using `saturating_sub` when plain `-` will do. `-` is cheaper - it's a single assembly instruction, whereas `saturating_sub` is usually 3 instructions.
https://godbolt.org/z/fo8Tcx6bK
These 2 `#[inline(always)]` were introduced by accident by me just playing around in #4298. One should be kept, but the other one we should leave to compiler to decide.
When parsing a number which contains `_` separators, rather than looping
through the string once to remove separators, and then again to convert
to an `f64`, do it all in a single loop.
Co-authored-by: overlookmotel <557937+overlookmotel@users.noreply.github.com>
Fix tests for parsing large numbers.
* Tests for imprecision decimals and octals weren't using numbers larger than `u64::MAX`, so were not testing what they were meant to be - that parser can handle larger numbers.
* Tests for decimals (e.g. `123.5`) were calling `parse_int` which isn't meant to handle that (`parse_float` does that).
* Tests were calling `parse_int` with negative numbers, which it's not meant to handle.
Also, re-order the const assertions in same order as the code above.
