Panic with unfinished f-string #8065
Comments
|
\cc @dhruvmanila |
|
I guess this is arguably an "incorrect" debug assertion? 🤔 |
Probably. The lexer works as it'll give out the error token stating that the string is unterminated but we flatten the token iterator ( But, then if we remove the assertion, the ranges could potentially be incomplete. For instance, the above example means that there's a The reason to use We could potentially avoid unwrapping by skipping the check for that f-string which seems like the correct behavior. That change will be dependent on where the ranges are being asked for. |
|
(Removed the "parser" label because the problem is with the |
Possible solutions:
The previous behavior (without PEP 701 support) matched (1) so I'll go with that. |
## Summary
This PR removes the `debug_assertion` in the `Indexer` to allow
unterminated f-strings. This is mainly a fix in the development build
which now matches the release build.
The fix is simple: remove the `debug_assertion` which means that the
there could be `FStringStart` and possibly `FStringMiddle` tokens
without a corresponding f-string range in the `Indexer`. This means that
the code requesting for the f-string index need to account for the
`None` case, making the code safer.
This also updates the code which queries the `FStringRanges` to account
for the `None` case. This will happen when the `FStringStart` /
`FStringMiddle` tokens are present but the `FStringEnd` token isn't
which means that the `Indexer` won't contain the range for that
f-string.
## Test Plan
`cargo test`
Taking the following code as an example:
```python
f"{123}
```
This only emits a `FStringStart` token, but no `FStringMiddle` or
`FStringEnd` tokens.
And,
```python
f"\.png${
```
This emits a `FStringStart` and `FStringMiddle` token, but no
`FStringEnd` token.
fixes: #8065
Running ruff with
f"{123}(note the missing closing quote) panics:
The text was updated successfully, but these errors were encountered: