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.

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

Linter panic: f-string error location miscomputation #9379

Closed
Tracked by #4972
addisoncrump opened this issue Jan 3, 2024 · 0 comments · Fixed by #9388
Closed
Tracked by #4972

Linter panic: f-string error location miscomputation #9379

addisoncrump opened this issue Jan 3, 2024 · 0 comments · Fixed by #9388
Assignees
Labels
bug Something isn't working fuzzer Surfaced via fuzzing.

Comments

@addisoncrump
Copy link
Contributor

Similar to #5004, but occurs outside of the f-string.

Consider the following source snippet:

F"{"ڤ

Which corresponds to the following hexdump:

00000000: 4622 7b22 daa4                           F"{"..

This results in the following crash dump due to an invalid char offset:

error: Panicked while linting test.py: This indicates a bug in Ruff. If you could open an issue at:

    https://github.com/astral-sh/ruff/issues/new?title=%5BLinter%20panic%5D

...with the relevant file contents, the `pyproject.toml` settings, and the following stack trace, we'd be very appreciative!

panicked at /home/addisoncrump/git/ruff/crates/ruff_source_file/src/locator.rs:396:23:
byte index 5 is not a char boundary; it is inside 'ڤ' (bytes 4..6) of `F"{"ڤ`
Backtrace:    0: ruff_cli::panic::catch_unwind::{{closure}}
   1: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/alloc/src/boxed.rs:2021:9
   2: std::panicking::rust_panic_with_hook
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:735:13
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:609:13
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/sys_common/backtrace.rs:170:18
   5: rust_begin_unwind
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:597:5
   6: core::panicking::panic_fmt
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/panicking.rs:72:14
   7: core::str::slice_error_fail_rt
   8: core::str::slice_error_fail
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/str/mod.rs:87:9
   9: ruff_linter::rules::pycodestyle::rules::errors::syntax_error
  10: ruff_linter::linter::check_path
  11: ruff_linter::linter::lint_only
  12: ruff_cli::diagnostics::lint_path
  13: ruff_cli::panic::catch_unwind
  14: ruff_cli::commands::check::lint_path
  15: rayon::iter::plumbing::Producer::fold_with
  16: rayon::iter::plumbing::bridge_producer_consumer::helper
  17: ruff_cli::commands::check::check
  18: ruff_cli::check
  19: ruff_cli::run
  20: ruff::main
  21: std::sys_common::backtrace::__rust_begin_short_backtrace
  22: std::rt::lang_start::{{closure}}
  23: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/ops/function.rs:284:13
  24: std::panicking::try::do_call
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:504:40
  25: std::panicking::try
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:468:19
  26: std::panic::catch_unwind
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panic.rs:142:14
  27: std::rt::lang_start_internal::{{closure}}
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/rt.rs:148:48
  28: std::panicking::try::do_call
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:504:40
  29: std::panicking::try
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:468:19
  30: std::panic::catch_unwind
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panic.rs:142:14
  31: std::rt::lang_start_internal
             at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/rt.rs:148:20
  32: main
  33: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  34: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:392:3
  35: _start
@charliermarsh charliermarsh added bug Something isn't working fuzzer Surfaced via fuzzing. labels Jan 4, 2024
@charliermarsh charliermarsh self-assigned this Jan 4, 2024
charliermarsh added a commit that referenced this issue Jan 4, 2024
## Summary

Given:

```python
F"{"ڤ
```

We try to locate the "unclosed left brace" error by subtracting the
quote size from the lexer offset -- so we subtract 1 from the end of the
source, which puts us in the middle of a Unicode character. I don't
think we should try to adjust the offset in this way, since there can be
content _after_ the quote. For example, with the advent of PEP 701, this
string could reasonably be fixed as:

```python
F"{"ڤ"}"
````

Closes #9379.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fuzzer Surfaced via fuzzing.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants