Merge branch 'main' into implement_pylint_invalid_str_returnE0307

.devcontainer/devcontainer.json

@@ -0,0 +1,46 @@
+// For format details, see https://aka.ms/devcontainer.json. For config options, see the
+// README at: https://github.com/devcontainers/templates/tree/main/src/rust
+{
+	"name": "Ruff",
+	"image": "mcr.microsoft.com/devcontainers/rust:0-1-bullseye",
+	"mounts": [
+		{
+			"source": "devcontainer-cargo-cache-${devcontainerId}",
+			"target": "/usr/local/cargo",
+			"type": "volume"
+		}
+	],
+	"customizations": {
+		"codespaces": {
+			"openFiles": [
+				"CONTRIBUTING.md"
+			]
+		},
+		"vscode": {
+			"extensions": [
+				"ms-python.python",
+				"rust-lang.rust-analyzer",
+				"serayuzgur.crates",
+				"tamasfe.even-better-toml",
+				"Swellaby.vscode-rust-test-adapter",
+				"charliermarsh.ruff"
+			],
+			"settings": {
+				"rust-analyzer.updates.askBeforeDownload": false
+			}
+		}
+	},
+	// Features to add to the dev container. More info: https://containers.dev/features.
+	"features": {
+		"ghcr.io/devcontainers/features/python": {
+			"installTools": false
+		}
+	},
+	// Use 'forwardPorts' to make a list of ports inside the container available locally.
+	// "forwardPorts": [],
+	"postCreateCommand": ".devcontainer/post-create.sh"
+	// Configure tool-specific properties.
+	// "customizations": {},
+	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
+	// "remoteUser": "root"
+}

.devcontainer/post-create.sh

@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+
+rustup default < rust-toolchain
+rustup component add clippy rustfmt
+cargo install cargo-insta
+cargo fetch
+
+pip install maturin pre-commit

.editorconfig

@@ -14,4 +14,7 @@ indent_size = 2
 indent_size = 4
 
 [*.snap]
-trim_trailing_whitespace = false
+trim_trailing_whitespace = false
+
+[*.md]
+max_line_length = 100

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,15 @@
+<!--
+Thank you for contributing to Ruff! To help us out with reviewing, please consider the following:
+
+- Does this pull request include a summary of the change? (See below.)
+- Does this pull request include a descriptive title?
+- Does this pull request include references to any relevant issues?
+-->
+
+## Summary
+
+<!-- What's the purpose of the change? What does it do, and why? -->
+
+## Test Plan
+
+<!-- How was it tested? -->

.github/release.yml

@@ -1,5 +1,9 @@
 # https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#configuring-automatically-generated-release-notes
 changelog:
+  exclude:
+    labels:
+      - internal
+      - documentation
   categories:
     - title: Breaking Changes
       labels:
@@ -11,6 +15,7 @@ changelog:
     - title: Settings
       labels:
         - configuration
+        - cli
     - title: Bug Fixes
       labels:
         - bug

.github/workflows/docs.yaml

@@ -1,9 +1,9 @@
 name: mkdocs
 
 on:
-  release:
-    types: [published]
   workflow_dispatch:
+  release:
+    types: [ published ]
 
 jobs:
   mkdocs:

.github/workflows/flake8-to-ruff.yaml

@@ -52,7 +52,7 @@ jobs:
       - name: "Build wheels - universal2"
         uses: PyO3/maturin-action@v1
         with:
-          args: --release --universal2 --out dist -m ./${{ env.CRATE_NAME }}/Cargo.toml
+          args: --release --target universal2-apple-darwin --out dist -m ./${{ env.CRATE_NAME }}/Cargo.toml
       - name: "Install built wheel - universal2"
         run: |
           pip install dist/${{ env.CRATE_NAME }}-*universal2.whl --force-reinstall

.github/workflows/playground.yaml

@@ -2,8 +2,8 @@ name: "[Playground] Release"
 
 on:
   workflow_dispatch:
-  push:
-    branches: [main]
+  release:
+    types: [ published ]
 
 env:
   CARGO_INCREMENTAL: 0

.github/workflows/release.yaml

@@ -3,7 +3,7 @@ name: "[ruff] Release"
 on:
   workflow_dispatch:
   release:
-    types: [published]
+    types: [ published ]
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
@@ -94,7 +94,7 @@ jobs:
       - name: "Build wheels - universal2"
         uses: PyO3/maturin-action@v1
         with:
-          args: --release --universal2 --out dist
+          args: --release --target universal2-apple-darwin --out dist
       - name: "Test wheel - universal2"
         run: |
           pip install dist/${{ env.PACKAGE_NAME }}-*universal2.whl --force-reinstall
@@ -394,21 +394,22 @@ jobs:
       - musllinux
       - musllinux-cross
     if: "startsWith(github.ref, 'refs/tags/')"
+    environment:
+      name: release
+    permissions:
+      # For pypi trusted publishing
+      id-token: write
     steps:
       - uses: actions/download-artifact@v3
         with:
           name: wheels
-      - uses: actions/setup-python@v4
+          path: wheels
       - name: "Publish to PyPi"
-        env:
-          TWINE_USERNAME: __token__
-          TWINE_PASSWORD: ${{ secrets.RUFF_TOKEN }}
-        run: |
-          pip install --upgrade twine
-          twine upload --skip-existing *
-      - name: "Update pre-commit mirror"
-        run: |
-          curl -X POST -H "Accept: application/vnd.github+json" -H "Authorization: Bearer ${{ secrets.RUFF_PRE_COMMIT_PAT }}" -H "X-GitHub-Api-Version: 2022-11-28" https://api.github.com/repos/charliermarsh/ruff-pre-commit/dispatches --data '{"event_type": "pypi_release"}'
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          skip-existing: true
+          packages-dir: wheels
+          verbose: true
       - uses: actions/download-artifact@v3
         with:
           name: binaries
@@ -417,3 +418,22 @@ jobs:
         uses: softprops/action-gh-release@v1
         with:
           files: binaries/*
+
+  # After the release has been published, we update downstream repositories
+  # This is separate because if this fails the release is still fine, we just need to do some manual workflow triggers
+  update-dependents:
+    name: Release
+    runs-on: ubuntu-latest
+    needs: release
+    steps:
+      - name: "Update pre-commit mirror"
+        uses: actions/github-script@v6
+        with:
+          github-token: ${{ secrets.RUFF_PRE_COMMIT_PAT }}
+          script: |
+            github.rest.actions.createWorkflowDispatch({
+              owner: 'astral-sh',
+              repo: 'ruff-pre-commit',
+              workflow_id: 'main.yml',
+              ref: 'main',
+            })

.gitignore

@@ -1,10 +1,11 @@
-# Local cache
-.ruff_cache
 crates/ruff/resources/test/cpython
 mkdocs.yml
 .overrides
 ruff-old
 github_search*.jsonl
+schemastore
+.venv*
+scratch.py
 
 ###
 # Rust.gitignore

.markdownlint.yaml

@@ -0,0 +1,14 @@
+# default to true for all rules
+default: true
+
+# MD033/no-inline-html
+MD033: false
+
+# MD041/first-line-h1
+MD041: false
+
+# MD013/line-length
+MD013:
+  line_length: 100
+  code_blocks: false
+  ignore_code_blocks: true

.pre-commit-config.yaml

@@ -17,11 +17,6 @@ repos:
     rev: v0.33.0
     hooks:
       - id: markdownlint-fix
-        args:
-          - --disable
-          - MD013 # line-length
-          - MD033 # no-inline-html
-          - --
 
   - repo: https://github.com/crate-ci/typos
     rev: v1.14.8

BREAKING_CHANGES.md

@@ -86,7 +86,8 @@ the intention of adding a stable public API in the future.
 ### `select`, `extend-select`, `ignore`, and `extend-ignore` have new semantics ([#2312](https://github.com/charliermarsh/ruff/pull/2312))
 
 Previously, the interplay between `select` and its related options could lead to unexpected
-behavior. For example, `ruff --select E501 --ignore ALL` and `ruff --select E501 --extend-ignore ALL` behaved differently. (See [#2312](https://github.com/charliermarsh/ruff/pull/2312) for more
+behavior. For example, `ruff --select E501 --ignore ALL` and `ruff --select E501 --extend-ignore ALL`
+behaved differently. (See [#2312](https://github.com/charliermarsh/ruff/pull/2312) for more
 examples.)
 
 When Ruff determines the enabled rule set, it has to reconcile `select` and `ignore` from a variety

CONTRIBUTING.md

@@ -8,6 +8,7 @@ Welcome! We're happy to have you here. Thank you in advance for your contributio
   - [Project Structure](#project-structure)
   - [Example: Adding a new lint rule](#example-adding-a-new-lint-rule)
     - [Rule naming convention](#rule-naming-convention)
+    - [Rule testing: fixtures and snapshots](#rule-testing-fixtures-and-snapshots)
   - [Example: Adding a new configuration option](#example-adding-a-new-configuration-option)
 - [MkDocs](#mkdocs)
 - [Release Process](#release-process)
@@ -93,24 +94,32 @@ At time of writing, the repository includes the following crates:
 
 - `crates/ruff`: library crate containing all lint rules and the core logic for running them.
 - `crates/ruff_cli`: binary crate containing Ruff's command-line interface.
-- `crates/ruff_dev`: binary crate containing utilities used in the development of Ruff itself (e.g., `cargo dev generate-all`).
+- `crates/ruff_dev`: binary crate containing utilities used in the development of Ruff itself (e.g.,
+  `cargo dev generate-all`).
 - `crates/ruff_macros`: library crate containing macros used by Ruff.
-- `crates/ruff_python`: library crate implementing Python-specific functionality (e.g., lists of standard library modules by versionb).
+- `crates/ruff_python`: library crate implementing Python-specific functionality (e.g., lists of
+  standard library modules by version).
 - `crates/flake8_to_ruff`: binary crate for generating Ruff configuration from Flake8 configuration.
 
 ### Example: Adding a new lint rule
 
 At a high level, the steps involved in adding a new lint rule are as follows:
 
 1. Determine a name for the new rule as per our [rule naming convention](#rule-naming-convention).
+
 1. Create a file for your rule (e.g., `crates/ruff/src/rules/flake8_bugbear/rules/abstract_base_class.rs`).
+
 1. In that file, define a violation struct. You can grep for `#[violation]` to see examples.
-1. Map the violation struct to a rule code in `crates/ruff/src/registry.rs` (e.g., `E402`).
-1. Define the logic for triggering the violation in `crates/ruff/src/checkers/ast/mod.rs` (for AST-based
-   checks), `crates/ruff/src/checkers/tokens.rs` (for token-based checks), `crates/ruff/src/checkers/lines.rs`
-   (for text-based checks), or `crates/ruff/src/checkers/filesystem.rs` (for filesystem-based
-   checks).
-1. Add a test fixture.
+
+1. Map the violation struct to a rule code in `crates/ruff/src/codes.rs` (e.g., `E402`).
+
+1. Define the logic for triggering the violation in `crates/ruff/src/checkers/ast/mod.rs` (for
+   AST-based checks), `crates/ruff/src/checkers/tokens.rs` (for token-based checks),
+   `crates/ruff/src/checkers/lines.rs` (for text-based checks), or
+   `crates/ruff/src/checkers/filesystem.rs` (for filesystem-based checks).
+
+1. Add proper [testing](#rule-testing-fixtures-and-snapshots) for your rule.
+
 1. Update the generated files (documentation and generated code).
 
 To define the violation, start by creating a dedicated file for your rule under the appropriate
@@ -125,18 +134,8 @@ collecting diagnostics as it goes.
 If you need to inspect the AST, you can run `cargo dev print-ast` with a Python file. Grep
 for the `Check::new` invocations to understand how other, similar rules are implemented.
 
-To add a test fixture, create a file under `crates/ruff/resources/test/fixtures/[linter]`, named to match
-the code you defined earlier (e.g., `crates/ruff/resources/test/fixtures/pycodestyle/E402.py`). This file should
-contain a variety of violations and non-violations designed to evaluate and demonstrate the behavior
-of your lint rule.
-
-Run `cargo dev generate-all` to generate the code for your new fixture. Then run Ruff
-locally with (e.g.) `cargo run -p ruff_cli -- check crates/ruff/resources/test/fixtures/pycodestyle/E402.py --no-cache --select E402`.
-
-Once you're satisfied with the output, codify the behavior as a snapshot test by adding a new
-`test_case` macro in the relevant `crates/ruff/src/rules/[linter]/mod.rs` file. Then, run `cargo test`.
-Your test will fail, but you'll be prompted to follow-up with `cargo insta review`. Accept the
-generated snapshot, then commit the snapshot file alongside the rest of your changes.
+Once you're satisfied with your code, add tests for your rule. See [rule testing](#rule-testing-fixtures-and-snapshots)
+for more details.
 
 Finally, regenerate the documentation and generated code with `cargo dev generate-all`.
 
@@ -154,6 +153,38 @@ This implies that rule names:
 When re-implementing rules from other linters, this convention is given more importance than
 preserving the original rule name.
 
+#### Rule testing: fixtures and snapshots
+
+To test rules, Ruff uses snapshots of Ruff's output for a given file (fixture). Generally, there
+will be one file per rule (e.g., `E402.py`), and each file will contain all necessary examples of
+both violations and non-violations. `cargo insta review` will generate a snapshot file containing
+Ruff's output for each fixture, which you can then commit alongside your changes.
+
+Once you've completed the code for the rule itself, you can define tests with the following steps:
+
+1. Add a Python file to `crates/ruff/resources/test/fixtures/[linter]` that contains the code you
+   want to test. The file name should match the rule name (e.g., `E402.py`), and it should include
+   examples of both violations and non-violations.
+
+1. Run Ruff locally against your file and verify the output is as expected. Once you're satisfied
+   with the output (you see the violations you expect, and no others), proceed to the next step.
+   For example, if you're adding a new rule named `E402`, you would run:
+
+   ```shell
+   cargo run -p ruff_cli -- check crates/ruff/resources/test/fixtures/pycodestyle/E402.py --no-cache
+   ```
+
+1. Add the test to the relevant `crates/ruff/src/rules/[linter]/mod.rs` file. If you're contributing
+   a rule to a pre-existing set, you should be able to find a similar example to pattern-match
+   against. If you're adding a new linter, you'll need to create a new `mod.rs` file (see,
+   e.g., `crates/ruff/src/rules/flake8_bugbear/mod.rs`)
+
+1. Run `cargo test`. Your test will fail, but you'll be prompted to follow-up
+   with `cargo insta review`. Run `cargo insta review`, review and accept the generated snapshot,
+   then commit the snapshot file alongside the rest of your changes.
+
+1. Run `cargo test` again to ensure that your test passes.
+
 ### Example: Adding a new configuration option
 
 Ruff's user-facing settings live in a few different places.
@@ -184,6 +215,8 @@ Finally, regenerate the documentation and generated code with `cargo dev generat
 
 To preview any changes to the documentation locally:
 
+1. Install the [Rust toolchain](https://www.rust-lang.org/tools/install).
+
 1. Install MkDocs and Material for MkDocs with:
 
    ```shell