The documentation has stale configuration guidance and a few examples
that do not work as written. Clarify the prose and correct editor
configuration precedence, user-level configuration discovery, rule
descriptions, and the tutorial and configuration examples.
---------
Co-authored-by: Zanie Blue <zanie@openai.com>
Summary
--
This PR updates our default Python version to 3.11, in line with 3.10
reaching [EOL] next month, and
updates our latest Python version to 3.15. I followed last year's PR
(#20725) to find everywhere
that needed to change. Fortunately there were not as many test changes
needed as last year's
deferred annotation issues.
I also updated the language classifier in our pyproject.toml.
[EOL]: https://devguide.python.org/versions/#supported-versions
Test Plan
--
Existing tests with updated snapshots. Most of the updates were to
snapshots for TC001, TC002, and
TC003, which now default to the lazy-import fix.
After updating the snapshots, I tried to make sure we still had coverage
for whatever changed. That
meant adding a few more mdtests for the TC rules, and one small mdtest
for RUF017 to restore
coverage for the `functools.reduce` fix.
Update the editor documentation for the VS Code extension's transition
to always using Ruff's native language server.
Remove the retired `ruff-lsp` settings entries, links to those entries,
and obsolete setup notes while retaining migration examples and
replacement guidance. Document `ruff.nativeServer` as deprecated in Ruff
0.17 and describe `ruff.interpreter` solely in terms of executable
discovery.
Related: https://github.com/astral-sh/ruff/issues/28545,
https://github.com/astral-sh/ruff-vscode/pull/1170
<!-- codex-thread: 01a0c3c7-f498-7682-9193-6e0e5307066b -->
Summary
--
I wasn't really planning to do a full stabilization pass, but I quickly skimmed through `preview.rs`
and remembered that the isort pragma change was kind a bug fix but technically breaking and thought
we might want to stabilize it.
This PR stabilizes the isort pragma comment width handling introduced in #27313, along with the
related pragma handling for `E501` and `W505` from #24071. There was a comment about also
stabilizing the related formatter preview feature on the function from #24071, so that is stabilized
here too.
I'm fine holding off on this, especially if the formatter change is a better fit for the 2027 style
guide. Like I said above, I mostly wanted to stabilize the isort change, but that snowballed a bit
since the helpers were shared.
Test Plan
--
Updated existing snapshots
Summary
--
This is the CLI accompaniment to #27807. The main change here is showing
display-only fix diffs in
the CLI. However, display-only fixes don't have a corresponding flag
like `--unsafe-fixes`, and I
thought it would be weird to show them unconditionally when we don't do
the same for unsafe fixes,
so this PR also unconditionally renders unsafe fix diffs, even when that
flag isn't passed. We
already emit a note about the fix being unsafe, so I think it makes
sense always to show you the
fix, and make `--unsafe-fixes` enable actually applying the fix. We also
don't want to apply
display-only fixes, so enabling rendering of the fixes with
`--display-only-fixes` or similar would
also disagree with the semantics of the unsafe flag. I'm open to other
ideas here, though.
The sub-diagnostic for display-only fixes uses a higher severity than
the note for unsafe fixes and
renders in red, as shown below.
The change here also affects ty, which now has both unsafe and
display-only fixes.
I again checked what clippy and rustc do in these cases, and they don't
include any additional note or warning about the fix being unsafe:
<details><summary>Rust diagnostics</summary>
<p>
Here's a
[`clippy::needless_pass_by_value`](https://rust-lang.github.io/rust-clippy/rust-1.97.0/index.html#needless_pass_by_value)
diagnostic, which is `MaybeIncorrect` ( similar to our `Unsafe`):
```
warning: this argument is passed by value, but not consumed in the function body
--> src/main.rs:3:15
|
3 | fn size(data: Data) -> usize {
| ^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.97.0/index.html#needless_pass_by_value
= note: requested on the command line with `-W clippy::needless-pass-by-value`
help: consider taking a reference instead
|
3 | fn size(data: &Data) -> usize {
| +
```
and here's a rustc
[`LetLike`](https://github.com/rust-lang/rust/blob/8bab26f4f68e0e26f0bb7960be334d5b520ea452/compiler/rustc_trait_selection/src/errors.rs#L268-L288)
diagnostic, which is `has-placeholders` (similar to our `DisplayOnly`
but definitely produces invalid code in this case):
```
error[E0282]: type annotations needed for `Vec<_>`
--> placeholder.rs:2:9
|
2 | let values = Vec::new();
| ^^^^^^ ---------- type must be known at this point
|
help: consider giving `values` an explicit type, where the type for type parameter `T` is specified
|
2 | let values: Vec<T> = Vec::new();
| ++++++++
```
</p>
</details>
Fixes https://github.com/astral-sh/ty/issues/1679
Test Plan
--
Updated existing snapshots, and some manual testing in the CLI:
<img width="965" height="400" alt="image"
src="https://github.com/user-attachments/assets/888ad79a-6853-48d4-8344-48da4af47d74"
/>
---------
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Summary
--
As the title says, this PR extends our
[category](https://docs.astral.sh/ruff/linter/#rule-categories) docs to
include a migration guide explaining how to approach a migration to the
new categories. Initially I included a migration script and a
description of how it works, but if we're unlikely to remove linter
groups, it seems less helpful. Our recommendation is basically to
`extend-select` the new categories to round out your existing
configuration, and no dramatic migration is necessary.
I guess this is not really a "migration guide" anymore, as reflected in
the updated section title.
---------
Co-authored-by: Micha Reiser <micha@reiser.io>
Summary
--
This PR adds the `--untrusted-workspace` flag to the server CLI, which
informs the server that it's running in an untrusted workspace. When
this is the case, we fall back on the internal formatting backend
instead of using `uv format` to avoid reading uv configuration and
potentially installing packages based on it.
Test Plan
--
New server tests
Ruff and ty interpret `@list.py` as a response-file reference even when
that literal path exists. This can turn a filename supplied by an
integration into command-line options.
Give existing literal `@` paths precedence in both CLIs, including
dangling symlinks, arguments inside nested response files, and arguments
after `--`. When the literal path is absent, keep expanding the response
file. Both CLIs share the implementation in `ruff_cli`.
line-length is a global option, not under `lint.`
This was introduced in #25013, after which #25389 attempted to fix it.
However, that change was made in autogenerated docs only (instead of
fixing it at the source), and thus the fix was undone again in #25396.
This instead fixes the issue in the source code, followed by a `cargo
dev generate-all`.
## Summary
The `restriction` category description refers to “language features”. I
made the wording more general so it can also apply to 3rd party APIs.
I switched one rule, `pytest-fixture-autouse` into there, as it bans a
feature that is both considered idiomatic and has no replacement, which
was pointed out by a pytest maintainer and several users:
- https://github.com/astral-sh/ruff/issues/27959#issuecomment-5485836053
- https://github.com/astral-sh/ruff/issues/12491
The rule has been disabled because it was so contentious, only to later
be placed into the `pedantic` categories with many rules that actually
improve most code bases. This puts it in the appropriate category.
## Test Plan
I ran all the tests, and grepped the docs grepped for “restriction” and
“language feature” to make sure I didn’t miss any spot where the
categories are described.
Summary
--
This PR includes the contributor-facing documentation for the new
categories, as well as updated
rule acceptance guidelines built atop them.
I think we could also update our rule request template based on some of
these guidelines, but I'll save that for a follow-up once these are
solidified.
Test Plan
--
Future rule requests
---------
Co-authored-by: Micha Reiser <micha@reiser.io>
Summary
--
This includes the user-facing updates to our linter docs and selection
settings to accompany #27666.
Test Plan
--
A few existing snapshot updates but mostly users reading this
---------
Co-authored-by: Micha Reiser <micha@reiser.io>
## Summary
Add a section on `pycon` handling to the *Markdown code formatting*
section.
Fixes#27151
## Test Plan
- verified markdown output locally
- run `scripts/check_docs_formatted.py --generate-docs`
- run `mkdocs build --strict`
- run `mkdocs serve` and inspect the site preview
---------
Co-authored-by: Brent Westbrook <brentrwestbrook@gmail.com>
Summary
--
This makes sense to accompany `ruff: ignore` comments being stabilized.
The preview gate has been pushed down to cover only the names vs codes
decision. I'll flag this as a comment, but I wasn't totally sure about
the LSP case. I left using `ruff: ignore` in its suppression edits
preview-gated for now.
Test Plan
--
Existing tests, dropping one that showed the preview error with
`--add-ignore`. I left `--preview` in many of the tests to continue
testing the human-readable names but removed it from one.
This PR stabilizes the expanded default rule set currently in preview
and adds a new generated `Default Rules` page to the docs to avoid
needing to include a lengthy selector block in multiple places.
Summary
--
This PR stabilizes the Markdown formatting initially added in #22470. It
also reverts much of the
error plumbing in the LSP that was added in #24150. I considered keeping
the
`FormatResult::PreviewOnly` variant but went ahead and dropped it since
it was unused.
Closes#26866.
Test Plan
--
Updated existing snapshots, dropping `--preview` in some cases
Closes#21894 by adding a section about argfile support (using `@`) to
the configuration documentation.
---------
Co-authored-by: Mahadev Annabhimoju <219508079+Joosboy@users.noreply.github.com>
