mirror of
https://github.com/astral-sh/ruff.git
synced 2025-09-13 22:06:42 +00:00
3ada36b766
## Summary part of: #15655 I tried generating the source order function using code generation. I tried a simple approach, but it is not enough to generate all of them this way. There is one good thing, that most of the implementations are fine with this. We only have a few that are not. So one benefit of this PR could be it eliminates a lot of the code, hence changing the AST structure will only leave a few places to be fixed. The `source_order` field determines if a node requires a source order implementation. If it’s empty it means source order does not visit anything. Initially I didn’t want to repeat the field names. But I found two things: - `ExprIf` statement unlike other statements does not have the fields defined in source order. This and also some fields do not need to be included in the visit. So we just need a way to determine order, and determine presence. - Relying on the fields sounds more complicated to me. Maybe another solution is to add a new attribute `order` to each field? I'm open to suggestions. But anyway, except for the `ExprIf` we don't need to write the field names in order. Just knowing what fields must be visited are enough. Some nodes had a more complex visitor: `ExprCompare` required zipping two fields. `ExprBoolOp` required a match over the fields. `FstringValue` required a match, I created a new walk_ function that does the match. and used it in code generation. I don’t think this provides real value. Because I mostly moved the code from one file to another. I was tried it as an option. I prefer to leave it in the code as before. Some visitors visit a slice of items. Others visit a single element. I put a check on this in code generation to see if the field requires a for loop or not. I think better approach is to have a consistent style. So we can by default loop over any field that is a sequence. For field types `StringLiteralValue` and `BytesLiteralValue` the types are not a sequence in toml definition. But they implement `iter` so they are iterated over. So the code generation does not properly identify this. So in the code I'm checking for their types. ## Test Plan All the tests should pass without any changes. I checked the generated code to make sure it's the same as old code. I'm not sure if there's a test for the source order visitor. |
||
|---|---|---|
| .. | ||
| red_knot | ||
| red_knot_ide | ||
| red_knot_project | ||
| red_knot_python_semantic | ||
| red_knot_server | ||
| red_knot_test | ||
| red_knot_vendored | ||
| red_knot_wasm | ||
| ruff | ||
| ruff_annotate_snippets | ||
| ruff_benchmark | ||
| ruff_cache | ||
| ruff_db | ||
| ruff_dev | ||
| ruff_diagnostics | ||
| ruff_formatter | ||
| ruff_graph | ||
| ruff_index | ||
| ruff_linter | ||
| ruff_macros | ||
| ruff_notebook | ||
| ruff_python_ast | ||
| ruff_python_ast_integration_tests | ||
| ruff_python_codegen | ||
| ruff_python_formatter | ||
| ruff_python_index | ||
| ruff_python_literal | ||
| ruff_python_parser | ||
| ruff_python_resolver | ||
| ruff_python_semantic | ||
| ruff_python_stdlib | ||
| ruff_python_trivia | ||
| ruff_python_trivia_integration_tests | ||
| ruff_server | ||
| ruff_source_file | ||
| ruff_text_size | ||
| ruff_wasm | ||
| ruff_workspace | ||