Commit Graph

12 Commits

Author SHA1 Message Date
Charlie Marsh c1f0661225
Replace `parents` statement stack with a `Nodes` abstraction (#4233) 2023-05-06 16:12:41 +00:00
Charlie Marsh d919adc13c
Introduce a `ruff_python_semantic` crate (#3865) 2023-04-04 16:50:47 +00:00
Charlie Marsh d822e08111
Move `CallPath` into its own module (#3847) 2023-04-01 11:25:04 -04:00
Charlie Marsh 88308ef9cc
Move `Binding` structs out of `scope.rs` (#3842) 2023-03-31 23:49:48 -04:00
Charlie Marsh 6d80c79bac
Combine `operations.rs` and `helpers.rs` (#3841) 2023-04-01 03:40:34 +00:00
Charlie Marsh 2fbc620ad3
Move `__all__` utilities to `all.rs` (#3840) 2023-04-01 03:31:15 +00:00
Charlie Marsh f79506f5a4
Move some generic structs out of `isort` (#3788) 2023-03-30 08:58:01 -04:00
Micha Reiser 000394f428
perf(pycodestyle): Introduce TokenKind (#3745) 2023-03-28 11:22:39 +02:00
Micha Reiser dedf4cbdeb
refactor: Move scope and binding types to `scope.rs` (#3573) 2023-03-17 17:31:33 +01:00
Charlie Marsh c2750a59ab
Implement an iterator for universal newlines (#3454)
# Summary

We need to support CR line endings (as opposed to LF and CRLF line endings, which are already supported). They're rare, but they do appear in Python code, and we tend to panic on any file that uses them.

Our `Locator` abstraction now supports CR line endings. However, Rust's `str#lines` implementation does _not_.

This PR adds a `UniversalNewlineIterator` implementation that respects all of CR, LF, and CRLF line endings, and plugs it into most of the `.lines()` call sites.

As an alternative design, it could be nice if we could leverage `Locator` for this. We've already computed all of the line endings, so we could probably iterate much more efficiently?

# Test Plan

Largely relying on automated testing, however, also ran over some known failure cases, like #3404.
2023-03-13 00:01:29 -04:00
Charlie Marsh ff2c0dd491
Use shared `leading_quote` implementation in ruff_python_formatter (#3396) 2023-03-08 18:21:59 +00:00
Charlie Marsh bad6bdda1f
Create a `rust_python_ast` crate (#3370)
This PR productionizes @MichaReiser's suggestion in https://github.com/charliermarsh/ruff/issues/1820#issuecomment-1440204423, by creating a separate crate for the `ast` module (`rust_python_ast`). This will enable us to further split up the `ruff` crate, as we'll be able to create (e.g.) separate sub-linter crates that have access to these common AST utilities.

This was mostly a straightforward copy (with adjustments to module imports), as the few dependencies that _did_ require modifications were handled in #3366, #3367, and #3368.
2023-03-07 15:18:40 +00:00