1
3
mirror of https://github.com/charliermarsh/ruff synced 2025-10-05 23:52:47 +02:00
Files
ruff/ty.schema.json

1099 lines
70 KiB
JSON
Raw Permalink Normal View History

Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Options",
"type": "object",
"properties": {
"environment": {
"description": "Configures the type checking environment.",
"anyOf": [
{
"$ref": "#/definitions/EnvironmentOptions"
},
{
"type": "null"
}
]
},
"overrides": {
"description": "Override configurations for specific file patterns.\n\nEach override specifies include/exclude patterns and rule configurations that apply to matching files. Multiple overrides can match the same file, with later overrides taking precedence.",
"type": [
"array",
"null"
],
"items": {
"$ref": "#/definitions/OverrideOptions"
}
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"rules": {
"description": "Configures the enabled rules and their severity.\n\nSee [the rules documentation](https://ty.dev/rules) for a list of all available rules.\n\nValid severities are:\n\n* `ignore`: Disable the rule. * `warn`: Enable the rule and create a warning diagnostic. * `error`: Enable the rule and create an error diagnostic. ty will exit with a non-zero code if any error diagnostics are emitted.",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"anyOf": [
{
"$ref": "#/definitions/Rules"
},
{
"type": "null"
}
]
},
"src": {
"anyOf": [
{
"$ref": "#/definitions/SrcOptions"
},
{
"type": "null"
}
]
},
"terminal": {
"anyOf": [
{
"$ref": "#/definitions/TerminalOptions"
},
{
"type": "null"
}
]
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
}
},
"additionalProperties": false,
"definitions": {
"EnvironmentOptions": {
"type": "object",
"properties": {
"extra-paths": {
"description": "List of user-provided paths that should take first priority in the module resolution. Examples in other type checkers are mypy's `MYPYPATH` environment variable, or pyright's `stubPath` configuration setting.",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"type": [
"array",
"null"
],
"items": {
"type": "string"
}
},
"python": {
2025-05-03 19:49:15 +02:00
"description": "Path to the Python installation from which ty resolves type information and third-party dependencies.\n\nty will search in the path's `site-packages` directories for type information and third-party imports.\n\nThis option is commonly used to specify the path to a virtual environment.",
"type": [
"string",
"null"
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"python-platform": {
"description": "Specifies the target platform that will be used to analyze the source code. If specified, ty will understand conditions based on comparisons with `sys.platform`, such as are commonly found in typeshed to reflect the differing contents of the standard library across platforms. If `all` is specified, ty will assume that the source code can run on any platform.\n\nIf no platform is specified, ty will use the current platform: - `win32` for Windows - `darwin` for macOS - `android` for Android - `ios` for iOS - `linux` for everything else",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"anyOf": [
{
"$ref": "#/definitions/PythonPlatform"
},
{
"type": "null"
}
]
},
"python-version": {
"description": "Specifies the version of Python that will be used to analyze the source code. The version should be specified as a string in the format `M.m` where `M` is the major version and `m` is the minor (e.g. `\"3.0\"` or `\"3.6\"`). If a version is provided, ty will generate errors if the source code makes use of language features that are not supported in that version.\n\nIf a version is not specified, ty will try the following techniques in order of preference to determine a value: 1. Check for the `project.requires-python` setting in a `pyproject.toml` file and use the minimum version from the specified range 2. Check for an activated or configured Python environment and attempt to infer the Python version of that environment 3. Fall back to the default value (see below)\n\nFor some language features, ty can also understand conditionals based on comparisons with `sys.version_info`. These are commonly found in typeshed, for example, to reflect the differing contents of the standard library across Python versions.",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"anyOf": [
{
"$ref": "#/definitions/PythonVersion"
},
{
"type": "null"
}
]
},
"root": {
"description": "The root paths of the project, used for finding first-party modules.\n\nAccepts a list of directory paths searched in priority order (first has highest priority).\n\nIf left unspecified, ty will try to detect common project layouts and initialize `root` accordingly:\n\n* if a `./src` directory exists, include `.` and `./src` in the first party search path (src layout or flat) * if a `./<project-name>/<project-name>` directory exists, include `.` and `./<project-name>` in the first party search path * otherwise, default to `.` (flat layout)\n\nBesides, if a `./python` or `./tests` directory exists and is not a package (i.e. it does not contain an `__init__.py` or `__init__.pyi` file), it will also be included in the first party search path.",
"type": [
"array",
"null"
],
"items": {
"type": "string"
}
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"typeshed": {
"description": "Optional path to a \"typeshed\" directory on disk for us to use for standard-library types. If this is not provided, we will fallback to our vendored typeshed stubs for the stdlib, bundled as a zip file in the binary",
"type": [
"string",
"null"
]
}
},
"additionalProperties": false
},
"Level": {
"oneOf": [
{
"title": "Ignore",
"description": "The lint is disabled and should not run.",
"type": "string",
"enum": [
"ignore"
]
},
{
"title": "Warn",
"description": "The lint is enabled and diagnostic should have a warning severity.",
"type": "string",
"enum": [
"warn"
]
},
{
"title": "Error",
"description": "The lint is enabled and diagnostics have an error severity.",
"type": "string",
"enum": [
"error"
]
}
]
},
Render Azure, JSON, and JSON lines output with the new diagnostics (#19133) ## Summary This was originally stacked on #19129, but some of the changes I made for JSON also impacted the Azure format, so I went ahead and combined them. The main changes here are: - Implementing `FileResolver` for Ruff's `EmitterContext` - Adding `FileResolver::notebook_index` and `FileResolver::is_notebook` methods - Adding a `DisplayDiagnostics` (with an "s") type for rendering a group of diagnostics at once - Adding `Azure`, `Json`, and `JsonLines` as new `DiagnosticFormat`s I tried a couple of alternatives to the `FileResolver::notebook` methods like passing down the `NotebookIndex` separately and trying to reparse a `Notebook` from Ruff's `SourceFile`. The latter seemed promising, but the `SourceFile` only stores the concatenated plain text of the notebook, not the re-parsable JSON. I guess the current version is just a variation on passing the `NotebookIndex`, but at least we can reuse the existing `resolver` argument. I think a lot of this can be cleaned up once Ruff has its own actual file resolver. As suggested, I also tried deleting the corresponding `Emitter` files in `ruff_linter`, but it doesn't look like git was able to follow this as a rename. It did, however, track that the tests were moved, so the snapshots should be easy to review. ## Test Plan Existing Ruff tests ported to tests in `ruff_db`. I think some other existing ruff tests also cover parts of this refactor. --------- Co-authored-by: Micha Reiser <micha@reiser.io>
2025-07-11 15:04:46 -04:00
"OutputFormat": {
"description": "The diagnostic output format.",
"oneOf": [
{
"description": "The default full mode will print \"pretty\" diagnostics.\n\nThat is, color will be used when printing to a `tty`. Moreover, diagnostic messages may include additional context and annotations on the input to help understand the message.",
"type": "string",
"enum": [
"full"
]
},
{
"description": "Print diagnostics in a concise mode.\n\nThis will guarantee that each diagnostic is printed on a single line. Only the most important or primary aspects of the diagnostic are included. Contextual information is dropped.\n\nThis may use color when printing to a `tty`.",
"type": "string",
"enum": [
"concise"
]
},
{
"description": "Print diagnostics in the JSON format expected by GitLab [Code Quality] reports.\n\n[Code Quality]: https://docs.gitlab.com/ci/testing/code_quality/#code-quality-report-format",
"type": "string",
"enum": [
"gitlab"
]
},
{
"description": "Print diagnostics in the format used by [GitHub Actions] workflow error annotations.\n\n[GitHub Actions]: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands#setting-an-error-message",
"type": "string",
"enum": [
"github"
]
Render Azure, JSON, and JSON lines output with the new diagnostics (#19133) ## Summary This was originally stacked on #19129, but some of the changes I made for JSON also impacted the Azure format, so I went ahead and combined them. The main changes here are: - Implementing `FileResolver` for Ruff's `EmitterContext` - Adding `FileResolver::notebook_index` and `FileResolver::is_notebook` methods - Adding a `DisplayDiagnostics` (with an "s") type for rendering a group of diagnostics at once - Adding `Azure`, `Json`, and `JsonLines` as new `DiagnosticFormat`s I tried a couple of alternatives to the `FileResolver::notebook` methods like passing down the `NotebookIndex` separately and trying to reparse a `Notebook` from Ruff's `SourceFile`. The latter seemed promising, but the `SourceFile` only stores the concatenated plain text of the notebook, not the re-parsable JSON. I guess the current version is just a variation on passing the `NotebookIndex`, but at least we can reuse the existing `resolver` argument. I think a lot of this can be cleaned up once Ruff has its own actual file resolver. As suggested, I also tried deleting the corresponding `Emitter` files in `ruff_linter`, but it doesn't look like git was able to follow this as a rename. It did, however, track that the tests were moved, so the snapshots should be easy to review. ## Test Plan Existing Ruff tests ported to tests in `ruff_db`. I think some other existing ruff tests also cover parts of this refactor. --------- Co-authored-by: Micha Reiser <micha@reiser.io>
2025-07-11 15:04:46 -04:00
}
]
},
"OverrideOptions": {
"type": "object",
"properties": {
"exclude": {
"description": "A list of file and directory patterns to exclude from this override.\n\nPatterns follow a syntax similar to `.gitignore`. Exclude patterns take precedence over include patterns within the same override.\n\nIf not specified, defaults to `[]` (excludes no files).",
"type": [
"array",
"null"
],
"items": {
"type": "string"
}
},
"include": {
"description": "A list of file and directory patterns to include for this override.\n\nThe `include` option follows a similar syntax to `.gitignore` but reversed: Including a file or directory will make it so that it (and its contents) are affected by this override.\n\nIf not specified, defaults to `[\"**\"]` (matches all files).",
"type": [
"array",
"null"
],
"items": {
"type": "string"
}
},
"rules": {
"description": "Rule overrides for files matching the include/exclude patterns.\n\nThese rules will be merged with the global rules, with override rules taking precedence for matching files. You can set rules to different severity levels or disable them entirely.",
"anyOf": [
{
"$ref": "#/definitions/Rules"
},
{
"type": "null"
}
]
}
},
"additionalProperties": false
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"PythonPlatform": {
"description": "The target platform to assume when resolving types.\n",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"anyOf": [
{
"type": "string"
},
{
"description": "Do not make any assumptions about the target platform.",
"const": "all"
},
{
"description": "Darwin",
"const": "darwin"
},
{
"description": "Linux",
"const": "linux"
},
{
"description": "Windows",
"const": "win32"
}
]
},
"PythonVersion": {
"anyOf": [
{
"type": "string",
"pattern": "^\\d+\\.\\d+$"
},
{
"description": "Python 3.7",
"const": "3.7"
},
{
"description": "Python 3.8",
"const": "3.8"
},
{
"description": "Python 3.9",
"const": "3.9"
},
{
"description": "Python 3.10",
"const": "3.10"
},
{
"description": "Python 3.11",
"const": "3.11"
},
{
"description": "Python 3.12",
"const": "3.12"
},
{
"description": "Python 3.13",
"const": "3.13"
},
{
"description": "Python 3.14",
"const": "3.14"
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
}
]
},
"Rules": {
"type": "object",
"properties": {
"ambiguous-protocol-member": {
"title": "detects protocol classes with ambiguous interfaces",
"description": "## What it does\nChecks for protocol classes with members that will lead to ambiguous interfaces.\n\n## Why is this bad?\nAssigning to an undeclared variable in a protocol class leads to an ambiguous\ninterface which may lead to the type checker inferring unexpected things. It's\nrecommended to ensure that all members of a protocol class are explicitly declared.\n\n## Examples\n\n```py\nfrom typing import Protocol\n\nclass BaseProto(Protocol):\n a: int # fine (explicitly declared as `int`)\n def method_member(self) -> int: ... # fine: a method definition using `def` is considered a declaration\n c = \"some variable\" # error: no explicit declaration, leading to ambiguity\n b = method_member # error: no explicit declaration, leading to ambiguity\n\n # error: this creates implicit assignments of `d` and `e` in the protocol class body.\n # Were they really meant to be considered protocol members?\n for d, e in enumerate(range(42)):\n pass\n\nclass SubProto(BaseProto, Protocol):\n a = 42 # fine (declared in superclass)\n```",
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"byte-string-type-annotation": {
"title": "detects byte strings in type annotation positions",
"description": "## What it does\nChecks for byte-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use byte-string notation.\n\n## Examples\n```python\ndef test(): -> b\"int\":\n ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n ...\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"call-non-callable": {
"title": "detects calls to non-callable objects",
"description": "## What it does\nChecks for calls to non-callable objects.\n\n## Why is this bad?\nCalling a non-callable object will raise a `TypeError` at runtime.\n\n## Examples\n```python\n4() # TypeError: 'int' object is not callable\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"conflicting-argument-forms": {
"title": "detects when an argument is used as both a value and a type form in a call",
[ty] eliminate is_fully_static (#18799) ## Summary Having a recursive type method to check whether a type is fully static is inefficient, unnecessary, and makes us overly strict about subtyping relations. It's inefficient because we end up re-walking the same types many times to check for fully-static-ness. It's unnecessary because we can check relations involving the dynamic type appropriately, depending whether the relation is subtyping or assignability. We use the subtyping relation to simplify unions and intersections. We can usefully consider that `S <: T` for gradual types also, as long as it remains true that `S | T` is equivalent to `T` and `S & T` is equivalent to `S`. One conservative definition (implemented here) that satisfies this requirement is that we consider `S <: T` if, for every possible pair of materializations `S'` and `T'`, `S' <: T'`. Or put differently the top materialization of `S` (`S+` -- the union of all possible materializations of `S`) is a subtype of the bottom materialization of `T` (`T-` -- the intersection of all possible materializations of `T`). In the most basic cases we can usefully say that `Any <: object` and that `Never <: Any`, and we can handle more complex cases inductively from there. This definition of subtyping for gradual subtypes is not reflexive (`Any` is not a subtype of `Any`). As a corollary, we also remove `is_gradual_equivalent_to` -- `is_equivalent_to` now has the meaning that `is_gradual_equivalent_to` used to have. If necessary, we could restore an `is_fully_static_equivalent_to` or similar (which would not do an `is_fully_static` pre-check of the types, but would instead pass a relation-kind enum down through a recursive equivalence check, similar to `has_relation_to`), but so far this doesn't appear to be necessary. Credit to @JelleZijlstra for the observation that `is_fully_static` is unnecessary and overly restrictive on subtyping. There is another possible definition of gradual subtyping: instead of requiring that `S+ <: T-`, we could instead require that `S+ <: T+` and `S- <: T-`. In other words, instead of requiring all materializations of `S` to be a subtype of every materialization of `T`, we just require that every materialization of `S` be a subtype of _some_ materialization of `T`, and that every materialization of `T` be a supertype of some materialization of `S`. This definition also preserves the core invariant that `S <: T` implies that `S | T = T` and `S & T = S`, and it restores reflexivity: under this definition, `Any` is a subtype of `Any`, and for any equivalent types `S` and `T`, `S <: T` and `T <: S`. But unfortunately, this definition breaks transitivity of subtyping, because nominal subclasses in Python use assignability ("consistent subtyping") to define acceptable overrides. This means that we may have a class `A` with `def method(self) -> Any` and a subtype `B(A)` with `def method(self) -> int`, since `int` is assignable to `Any`. This means that if we have a protocol `P` with `def method(self) -> Any`, we would have `B <: A` (from nominal subtyping) and `A <: P` (`Any` is a subtype of `Any`), but not `B <: P` (`int` is not a subtype of `Any`). Breaking transitivity of subtyping is not tenable, so we don't use this definition of subtyping. ## Test Plan Existing tests (modified in some cases to account for updated semantics.) Stable property tests pass at a million iterations: `QUICKCHECK_TESTS=1000000 cargo test -p ty_python_semantic -- --ignored types::property_tests::stable` ### Changes to property test type generation Since we no longer have a method of categorizing built types as fully-static or not-fully-static, I had to add a previously-discussed feature to the property tests so that some tests can build types that are known by construction to be fully static, because there are still properties that only apply to fully-static types (for example, reflexiveness of subtyping.) ## Changes to handling of `*args, **kwargs` signatures This PR "discovered" that, once we allow non-fully-static types to participate in subtyping under the above definitions, `(*args: Any, **kwargs: Any) -> Any` is now a subtype of `() -> object`. This is true, if we take a literal interpretation of the former signature: all materializations of the parameters `*args: Any, **kwargs: Any` can accept zero arguments, making the former signature a subtype of the latter. But the spec actually says that `*args: Any, **kwargs: Any` should be interpreted as equivalent to `...`, and that makes a difference here: `(...) -> Any` is not a subtype of `() -> object`, because (unlike a literal reading of `(*args: Any, **kwargs: Any)`), `...` can materialize to _any_ signature, including a signature with required positional arguments. This matters for this PR because it makes the "any two types are both assignable to their union" property test fail if we don't implement the equivalence to `...`. Because `FunctionType.__call__` has the signature `(*args: Any, **kwargs: Any) -> Any`, and if we take that at face value it's a subtype of `() -> object`, making `FunctionType` a subtype of `() -> object)` -- but then a function with a required argument is also a subtype of `FunctionType`, but not a subtype of `() -> object`. So I went ahead and implemented the equivalence to `...` in this PR. ## Ecosystem analysis * Most of the ecosystem report are cases of improved union/intersection simplification. For example, we can now simplify a union like `bool | (bool & Unknown) | Unknown` to simply `bool | Unknown`, because we can now observe that every possible materialization of `bool & Unknown` is still a subtype of `bool` (whereas before we would set aside `bool & Unknown` as a not-fully-static type.) This is clearly an improvement. * The `possibly-unresolved-reference` errors in sockeye, pymongo, ignite, scrapy and others are true positives for conditional imports that were formerly silenced by bogus conflicting-declarations (which we currently don't issue a diagnostic for), because we considered two different declarations of `Unknown` to be conflicting (we used `is_equivalent_to` not `is_gradual_equivalent_to`). In this PR that distinction disappears and all equivalence is gradual, so a declaration of `Unknown` no longer conflicts with a declaration of `Unknown`, which then results in us surfacing the possibly-unbound error. * We will now issue "redundant cast" for casting from a typevar with a gradual bound to the same typevar (the hydra-zen diagnostic). This seems like an improvement. * The new diagnostics in bandersnatch are interesting. For some reason primer in CI seems to be checking bandersnatch on Python 3.10 (not yet sure why; this doesn't happen when I run it locally). But bandersnatch uses `enum.StrEnum`, which doesn't exist on 3.10. That makes the `class SimpleDigest(StrEnum)` a class that inherits from `Unknown` (and bypasses our current TODO handling for accessing attributes on enum classes, since we don't recognize it as an enum class at all). This PR improves our understanding of assignability to classes that inherit from `Any` / `Unknown`, and we now recognize that a string literal is not assignable to a class inheriting `Any` or `Unknown`.
2025-06-24 18:02:05 -07:00
"description": "## What it does\nChecks whether an argument is used as both a value and a type form in a call.\n\n## Why is this bad?\nSuch calls have confusing semantics and often indicate a logic error.\n\n## Examples\n```python\nfrom typing import reveal_type\nfrom ty_extensions import is_singleton\n\nif flag:\n f = repr # Expects a value\nelse:\n f = is_singleton # Expects a type form\n\nf(int) # error\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"conflicting-declarations": {
"title": "detects conflicting declarations",
"description": "## What it does\nChecks whether a variable has been declared as two conflicting types.\n\n## Why is this bad\nA variable with two conflicting declarations likely indicates a mistake.\nMoreover, it could lead to incorrect or ill-defined type inference for\nother code that relies on these variables.\n\n## Examples\n```python\nif b:\n a: int\nelse:\n a: str\n\na = 1\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"conflicting-metaclass": {
"title": "detects conflicting metaclasses",
"description": "## What it does\nChecks for class definitions where the metaclass of the class\nbeing created would not be a subclass of the metaclasses of\nall the class's bases.\n\n## Why is it bad?\nSuch a class definition raises a `TypeError` at runtime.\n\n## Examples\n```python\nclass M1(type): ...\nclass M2(type): ...\nclass A(metaclass=M1): ...\nclass B(metaclass=M2): ...\n\n# TypeError: metaclass conflict\nclass C(A, B): ...\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"cyclic-class-definition": {
"title": "detects cyclic class definitions",
"description": "## What it does\nChecks for class definitions in stub files that inherit\n(directly or indirectly) from themselves.\n\n## Why is it bad?\nAlthough forward references are natively supported in stub files,\ninheritance cycles are still disallowed, as it is impossible to\nresolve a consistent [method resolution order] for a class that\ninherits from itself.\n\n## Examples\n```python\n# foo.pyi\nclass A(B): ...\nclass B(A): ...\n```\n\n[method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"deprecated": {
"title": "detects uses of deprecated items",
"description": "## What it does\nChecks for uses of deprecated items\n\n## Why is this bad?\nDeprecated items should no longer be used.\n\n## Examples\n```python\n@warnings.deprecated(\"use new_func instead\")\ndef old_func(): ...\n\nold_func() # emits [deprecated] diagnostic\n```",
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"division-by-zero": {
"title": "detects division by zero",
"description": "## What it does\nIt detects division by zero.\n\n## Why is this bad?\nDividing by zero raises a `ZeroDivisionError` at runtime.\n\n## Examples\n```python\n5 / 0\n```",
"default": "ignore",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"duplicate-base": {
"title": "detects class definitions with duplicate bases",
"description": "## What it does\nChecks for class definitions with duplicate bases.\n\n## Why is this bad?\nClass definitions with duplicate bases raise `TypeError` at runtime.\n\n## Examples\n```python\nclass A: ...\n\n# TypeError: duplicate base class\nclass B(A, A): ...\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"duplicate-kw-only": {
2025-07-02 16:32:11 +02:00
"title": "detects dataclass definitions with more than one usage of `KW_ONLY`",
"description": "## What it does\nChecks for dataclass definitions with more than one field\nannotated with `KW_ONLY`.\n\n## Why is this bad?\n`dataclasses.KW_ONLY` is a special marker used to\nemulate the `*` syntax in normal signatures.\nIt can only be used once per dataclass.\n\nAttempting to annotate two different fields with\nit will lead to a runtime error.\n\n## Examples\n```python\nfrom dataclasses import dataclass, KW_ONLY\n\n@dataclass\nclass A: # Crash at runtime\n b: int\n _1: KW_ONLY\n c: str\n _2: KW_ONLY\n d: bytes\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"escape-character-in-forward-annotation": {
"title": "detects forward type annotations with escape characters",
"description": "TODO #14889",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"fstring-type-annotation": {
"title": "detects F-strings in type annotation positions",
"description": "## What it does\nChecks for f-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use f-string notation.\n\n## Examples\n```python\ndef test(): -> f\"int\":\n ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n ...\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"implicit-concatenated-string-type-annotation": {
"title": "detects implicit concatenated strings in type annotations",
"description": "## What it does\nChecks for implicit concatenated strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use implicit concatenated strings.\n\n## Examples\n```python\ndef test(): -> \"Literal[\" \"5\" \"]\":\n ...\n```\n\nUse instead:\n```python\ndef test(): -> \"Literal[5]\":\n ...\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"inconsistent-mro": {
"title": "detects class definitions with an inconsistent MRO",
"description": "## What it does\nChecks for classes with an inconsistent [method resolution order] (MRO).\n\n## Why is this bad?\nClasses with an inconsistent MRO will raise a `TypeError` at runtime.\n\n## Examples\n```python\nclass A: ...\nclass B(A): ...\n\n# TypeError: Cannot create a consistent method resolution order\nclass C(A, B): ...\n```\n\n[method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"index-out-of-bounds": {
"title": "detects index out of bounds errors",
"description": "## What it does\nChecks for attempts to use an out of bounds index to get an item from\na container.\n\n## Why is this bad?\nUsing an out of bounds index will raise an `IndexError` at runtime.\n\n## Examples\n```python\nt = (0, 1, 2)\nt[3] # IndexError: tuple index out of range\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"instance-layout-conflict": {
"title": "detects class definitions that raise `TypeError` due to instance layout conflict",
2025-08-25 19:39:05 +01:00
"description": "## What it does\nChecks for classes definitions which will fail at runtime due to\n\"instance memory layout conflicts\".\n\nThis error is usually caused by attempting to combine multiple classes\nthat define non-empty `__slots__` in a class's [Method Resolution Order]\n(MRO), or by attempting to combine multiple builtin classes in a class's\nMRO.\n\n## Why is this bad?\nInheriting from bases with conflicting instance memory layouts\nwill lead to a `TypeError` at runtime.\n\nAn instance memory layout conflict occurs when CPython cannot determine\nthe memory layout instances of a class should have, because the instance\nmemory layout of one of its bases conflicts with the instance memory layout\nof one or more of its other bases.\n\nFor example, if a Python class defines non-empty `__slots__`, this will\nimpact the memory layout of instances of that class. Multiple inheritance\nfrom more than one different class defining non-empty `__slots__` is not\nallowed:\n\n```python\nclass A:\n __slots__ = (\"a\", \"b\")\n\nclass B:\n __slots__ = (\"a\", \"b\") # Even if the values are the same\n\n# TypeError: multiple bases have instance lay-out conflict\nclass C(A, B): ...\n```\n\nAn instance layout conflict can also be caused by attempting to use\nmultiple inheritance with two builtin classes, due to the way that these\nclasses are implemented in a CPython C extension:\n\n```python\nclass A(int, float): ... # TypeError: multiple bases have instance lay-out conflict\n```\n\nNote that pure-Python classes with no `__slots__`, or pure-Python classes\nwith empty `__slots__`, are always compatible:\n\n```python\nclass A: ...\nclass B:\n __slots__ = ()\nclass C:\n __slots__ = (\"a\", \"b\")\n\n# fine\nclass D(A, B, C): ...\n```\n\n## Known problems\nClasses that have \"dynamic\" definitions of `__slots__` (definitions do not consist\nof string literals, or tuples of string literals) are not currently considered disjoint\nbases by ty.\n\nAdditionally, this check is not exhaustive: many C extensions (including several in\nthe standard library) define classes that use extended memory layouts and thus cannot\ncoexist in a single MRO. Since it is currently not possible to represent this fact in\nstub files, having a full knowledge of these classes is also impossible. When it comes\nto classes that do not define `__slots__` at the Python level, therefore, ty, currently\nonly hard-codes a number of cases where it knows that a class will produce instances with\nan atypical memory layout.\n\n## Further reading\n- [CPython documentation: `__slots__`](https://docs.python.org/3/reference/datamodel.html#slots)\n- [CPython documentation: Method Resolution Order](https://docs.python.org/3/glossary.html#term-method-resolution-order)\n\n[Method Resolution Order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-argument-type": {
"title": "detects call arguments whose type is not assignable to the corresponding typed parameter",
"description": "## What it does\nDetects call arguments whose type is not assignable to the corresponding typed parameter.\n\n## Why is this bad?\nPassing an argument of a type the function (or callable object) does not accept violates\nthe expectations of the function author and may cause unexpected runtime errors within the\nbody of the function.\n\n## Examples\n```python\ndef func(x: int): ...\nfunc(\"foo\") # error: [invalid-argument-type]\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-assignment": {
"title": "detects invalid assignments",
"description": "## What it does\nChecks for assignments where the type of the value\nis not [assignable to] the type of the assignee.\n\n## Why is this bad?\nSuch assignments break the rules of the type system and\nweaken a type checker's ability to accurately reason about your code.\n\n## Examples\n```python\na: int = ''\n```\n\n[assignable to]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-attribute-access": {
"title": "Invalid attribute access",
"description": "## What it does\nChecks for assignments to class variables from instances\nand assignments to instance variables from its class.\n\n## Why is this bad?\nIncorrect assignments break the rules of the type system and\nweaken a type checker's ability to accurately reason about your code.\n\n## Examples\n```python\nclass C:\n class_var: ClassVar[int] = 1\n instance_var: int\n\nC.class_var = 3 # okay\nC().class_var = 3 # error: Cannot assign to class variable\n\nC().instance_var = 3 # okay\nC.instance_var = 3 # error: Cannot assign to instance variable\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
[ty] Add diagnostics for invalid `await` expressions (#19711) ## Summary This PR adds a new lint, `invalid-await`, for all sorts of reasons why an object may not be `await`able, as discussed in astral-sh/ty#919. Precisely, `__await__` is guarded against being missing, possibly unbound, or improperly defined (expects additional arguments or doesn't return an iterator). Of course, diagnostics need to be fine-tuned. If `__await__` cannot be called with no extra arguments, it indicates an error (or a quirk?) in the method signature, not at the call site. Without any doubt, such an object is not `Awaitable`, but I feel like talking about arguments for an *implicit* call is a bit leaky. I didn't reference any actual diagnostic messages in the lint definition, because I want to hear feedback first. Also, there's no mention of the actual required method signature for `__await__` anywhere in the docs. The only reference I had is the `typing` stub. I basically ended up linking `[Awaitable]` to ["must implement `__await__`"](https://docs.python.org/3/library/collections.abc.html#collections.abc.Awaitable), which is insufficient on its own. ## Test Plan The following code was tested: ```python import asyncio import typing class Awaitable: def __await__(self) -> typing.Generator[typing.Any, None, int]: yield None return 5 class NoDunderMethod: pass class InvalidAwaitArgs: def __await__(self, value: int) -> int: return value class InvalidAwaitReturn: def __await__(self) -> int: return 5 class InvalidAwaitReturnImplicit: def __await__(self): pass async def main() -> None: result = await Awaitable() # valid result = await NoDunderMethod() # `__await__` is missing result = await InvalidAwaitReturn() # `__await__` returns `int`, which is not a valid iterator result = await InvalidAwaitArgs() # `__await__` expects additional arguments and cannot be called implicitly result = await InvalidAwaitReturnImplicit() # `__await__` returns `Unknown`, which is not a valid iterator asyncio.run(main()) ``` --------- Co-authored-by: Carl Meyer <carl@astral.sh>
2025-08-15 00:38:33 +03:00
}
]
},
"invalid-await": {
"title": "detects awaiting on types that don't support it",
"description": "## What it does\nChecks for `await` being used with types that are not [Awaitable].\n\n## Why is this bad?\nSuch expressions will lead to `TypeError` being raised at runtime.\n\n## Examples\n```python\nimport asyncio\n\nclass InvalidAwait:\n def __await__(self) -> int:\n return 5\n\nasync def main() -> None:\n await InvalidAwait() # error: [invalid-await]\n await 42 # error: [invalid-await]\n\nasyncio.run(main())\n```\n\n[Awaitable]: https://docs.python.org/3/library/collections.abc.html#collections.abc.Awaitable",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
}
]
},
"invalid-base": {
"title": "detects class bases that will cause the class definition to raise an exception at runtime",
"description": "## What it does\nChecks for class definitions that have bases which are not instances of `type`.\n\n## Why is this bad?\nClass definitions with bases like this will lead to `TypeError` being raised at runtime.\n\n## Examples\n```python\nclass A(42): ... # error: [invalid-base]\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-context-manager": {
"title": "detects expressions used in with statements that don't implement the context manager protocol",
"description": "## What it does\nChecks for expressions used in `with` statements\nthat do not implement the context manager protocol.\n\n## Why is this bad?\nSuch a statement will raise `TypeError` at runtime.\n\n## Examples\n```python\n# TypeError: 'int' object does not support the context manager protocol\nwith 1:\n print(2)\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-declaration": {
"title": "detects invalid declarations",
"description": "## What it does\nChecks for declarations where the inferred type of an existing symbol\nis not [assignable to] its post-hoc declared type.\n\n## Why is this bad?\nSuch declarations break the rules of the type system and\nweaken a type checker's ability to accurately reason about your code.\n\n## Examples\n```python\na = 1\na: str\n```\n\n[assignable to]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-exception-caught": {
"title": "detects exception handlers that catch classes that do not inherit from `BaseException`",
2025-08-07 18:21:50 +02:00
"description": "## What it does\nChecks for exception handlers that catch non-exception classes.\n\n## Why is this bad?\nCatching classes that do not inherit from `BaseException` will raise a `TypeError` at runtime.\n\n## Example\n```python\ntry:\n 1 / 0\nexcept 1:\n ...\n```\n\nUse instead:\n```python\ntry:\n 1 / 0\nexcept ZeroDivisionError:\n ...\n```\n\n## References\n- [Python documentation: except clause](https://docs.python.org/3/reference/compound_stmts.html#except-clause)\n- [Python documentation: Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#built-in-exceptions)\n\n## Ruff rule\n This rule corresponds to Ruff's [`except-with-non-exception-classes` (`B030`)](https://docs.astral.sh/ruff/rules/except-with-non-exception-classes)",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-generic-class": {
"title": "detects invalid generic classes",
"description": "## What it does\nChecks for the creation of invalid generic classes\n\n## Why is this bad?\nThere are several requirements that you must follow when defining a generic class.\n\n## Examples\n```python\nfrom typing import Generic, TypeVar\n\nT = TypeVar(\"T\") # okay\n\n# error: class uses both PEP-695 syntax and legacy syntax\nclass C[U](Generic[T]): ...\n```\n\n## References\n- [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction)",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
},
"invalid-ignore-comment": {
"title": "detects ignore comments that use invalid syntax",
2025-05-03 19:49:15 +02:00
"description": "## What it does\nChecks for `type: ignore` and `ty: ignore` comments that are syntactically incorrect.\n\n## Why is this bad?\nA syntactically incorrect ignore comment is probably a mistake and is useless.\n\n## Examples\n```py\na = 20 / 0 # type: ignoree\n```\n\nUse instead:\n\n```py\na = 20 / 0 # type: ignore\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-key": {
"title": "detects invalid subscript accesses",
"description": "## What it does\nChecks for subscript accesses with invalid keys.\n\n## Why is this bad?\nUsing an invalid key will raise a `KeyError` at runtime.\n\n## Examples\n```python\nfrom typing import TypedDict\n\nclass Person(TypedDict):\n name: str\n age: int\n\nalice = Person(name=\"Alice\", age=30)\nalice[\"height\"] # KeyError: 'height'\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-legacy-type-variable": {
"title": "detects invalid legacy type variables",
"description": "## What it does\nChecks for the creation of invalid legacy `TypeVar`s\n\n## Why is this bad?\nThere are several requirements that you must follow when creating a legacy `TypeVar`.\n\n## Examples\n```python\nfrom typing import TypeVar\n\nT = TypeVar(\"T\") # okay\nQ = TypeVar(\"S\") # error: TypeVar name must match the variable it's assigned to\nT = TypeVar(\"T\") # error: TypeVars should not be redefined\n\n# error: TypeVar must be immediately assigned to a variable\ndef f(t: TypeVar(\"U\")): ...\n```\n\n## References\n- [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction)",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"invalid-metaclass": {
"title": "detects invalid `metaclass=` arguments",
"description": "## What it does\nChecks for arguments to `metaclass=` that are invalid.\n\n## Why is this bad?\nPython allows arbitrary expressions to be used as the argument to `metaclass=`.\nThese expressions, however, need to be callable and accept the same arguments\nas `type.__new__`.\n\n## Example\n\n```python\ndef f(): ...\n\n# TypeError: f() takes 0 positional arguments but 3 were given\nclass B(metaclass=f): ...\n```\n\n## References\n- [Python documentation: Metaclasses](https://docs.python.org/3/reference/datamodel.html#metaclasses)",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-named-tuple": {
"title": "detects invalid `NamedTuple` class definitions",
"description": "## What it does\nChecks for invalidly defined `NamedTuple` classes.\n\n## Why is this bad?\nAn invalidly defined `NamedTuple` class may lead to the type checker\ndrawing incorrect conclusions. It may also lead to `TypeError`s at runtime.\n\n## Examples\nA class definition cannot combine `NamedTuple` with other base classes\nin multiple inheritance; doing so raises a `TypeError` at runtime. The sole\nexception to this rule is `Generic[]`, which can be used alongside `NamedTuple`\nin a class's bases list.\n\n```pycon\n>>> from typing import NamedTuple\n>>> class Foo(NamedTuple, object): ...\nTypeError: can only inherit from a NamedTuple type and Generic\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
[red-knot] Check for invalid overload usages (#17609) ## Summary Part of #15383, this PR adds the core infrastructure to check for invalid overloads and adds a diagnostic to raise if there are < 2 overloads for a given definition. ### Design notes The requirements to check the overloads are: * Requires `FunctionType` which has the `to_overloaded` method * The `FunctionType` **should** be for the function that is either the implementation or the last overload if the implementation doesn't exists * Avoid checking any `FunctionType` that are part of an overload chain * Consider visibility constraints This required a couple of iteration to make sure all of the above requirements are fulfilled. #### 1. Use a set to deduplicate The logic would first collect all the `FunctionType` that are part of the overload chain except for the implementation or the last overload if the implementation doesn't exists. Then, when iterating over all the function declarations within the scope, we'd avoid checking these functions. But, this approach would fail to consider visibility constraints as certain overloads _can_ be behind a version check. Those aren't part of the overload chain but those aren't a separate overload chain either. <details><summary>Implementation:</summary> <p> ```rs fn check_overloaded_functions(&mut self) { let function_definitions = || { self.types .declarations .iter() .filter_map(|(definition, ty)| { // Filter out function literals that result from anything other than a function // definition e.g., imports. if let DefinitionKind::Function(function) = definition.kind(self.db()) { ty.inner_type() .into_function_literal() .map(|ty| (ty, definition.symbol(self.db()), function.node())) } else { None } }) }; // A set of all the functions that are part of an overloaded function definition except for // the implementation function and the last overload in case the implementation doesn't // exists. This allows us to collect all the function definitions that needs to be skipped // when checking for invalid overload usages. let mut overloads: HashSet<FunctionType<'db>> = HashSet::default(); for (function, _) in function_definitions() { let Some(overloaded) = function.to_overloaded(self.db()) else { continue; }; if overloaded.implementation.is_some() { overloads.extend(overloaded.overloads.iter().copied()); } else if let Some((_, previous_overloads)) = overloaded.overloads.split_last() { overloads.extend(previous_overloads.iter().copied()); } } for (function, function_node) in function_definitions() { let Some(overloaded) = function.to_overloaded(self.db()) else { continue; }; if overloads.contains(&function) { continue; } // At this point, the `function` variable is either the implementation function or the // last overloaded function if the implementation doesn't exists. if overloaded.overloads.len() < 2 { if let Some(builder) = self .context .report_lint(&INVALID_OVERLOAD, &function_node.name) { let mut diagnostic = builder.into_diagnostic(format_args!( "Function `{}` requires at least two overloads", &function_node.name )); if let Some(first_overload) = overloaded.overloads.first() { diagnostic.annotate( self.context .secondary(first_overload.focus_range(self.db())) .message(format_args!("Only one overload defined here")), ); } } } } } ``` </p> </details> #### 2. Define a `predecessor` query The `predecessor` query would return the previous `FunctionType` for the given `FunctionType` i.e., the current logic would be extracted to be a query instead. This could then be used to make sure that we're checking the entire overload chain once. The way this would've been implemented is to have a `to_overloaded` implementation which would take the root of the overload chain instead of the leaf. But, this would require updates to the use-def map to somehow be able to return the _following_ functions for a given definition. #### 3. Create a successor link This is what Pyrefly uses, we'd create a forward link between two functions that are involved in an overload chain. This means that for a given function, we can get the successor function. This could be used to find the _leaf_ of the overload chain which can then be used with the `to_overloaded` method to get the entire overload chain. But, this would also require updating the use-def map to be able to "see" the _following_ function. ### Implementation This leads us to the final implementation that this PR implements which is to consider the overloaded functions using: * Collect all the **function symbols** that are defined **and** called within the same file. This could potentially be an overloaded function * Use the public bindings to get the leaf of the overload chain and use that to get the entire overload chain via `to_overloaded` and perform the check This has a limitation that in case a function redefines an overload, then that overload will not be checked. For example: ```py from typing import overload @overload def f() -> None: ... @overload def f(x: int) -> int: ... # The above overload will not be checked as the below function with the same name # shadows it def f(*args: int) -> int: ... ``` ## Test Plan Update existing mdtest and add snapshot diagnostics.
2025-04-30 19:37:42 +05:30
"invalid-overload": {
"title": "detects invalid `@overload` usages",
"description": "## What it does\nChecks for various invalid `@overload` usages.\n\n## Why is this bad?\nThe `@overload` decorator is used to define functions and methods that accepts different\ncombinations of arguments and return different types based on the arguments passed. This is\nmainly beneficial for type checkers. But, if the `@overload` usage is invalid, the type\nchecker may not be able to provide correct type information.\n\n## Example\n\nDefining only one overload:\n\n```py\nfrom typing import overload\n\n@overload\ndef foo(x: int) -> int: ...\ndef foo(x: int | None) -> int | None:\n return x\n```\n\nOr, not providing an implementation for the overloaded definition:\n\n```py\nfrom typing import overload\n\n@overload\ndef foo() -> None: ...\n@overload\ndef foo(x: int) -> int: ...\n```\n\n## References\n- [Python documentation: `@overload`](https://docs.python.org/3/library/typing.html#typing.overload)",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"invalid-parameter-default": {
"title": "detects default values that can't be assigned to the parameter's annotated type",
"description": "## What it does\nChecks for default values that can't be\nassigned to the parameter's annotated type.\n\n## Why is this bad?\nThis breaks the rules of the type system and\nweakens a type checker's ability to accurately reason about your code.\n\n## Examples\n```python\ndef f(a: int = ''): ...\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-protocol": {
"title": "detects invalid protocol class definitions",
"description": "## What it does\nChecks for protocol classes that will raise `TypeError` at runtime.\n\n## Why is this bad?\nAn invalidly defined protocol class may lead to the type checker inferring\nunexpected things. It may also lead to `TypeError`s at runtime.\n\n## Examples\nA `Protocol` class cannot inherit from a non-`Protocol` class;\nthis raises a `TypeError` at runtime:\n\n```pycon\n>>> from typing import Protocol\n>>> class Foo(int, Protocol): ...\n...\nTraceback (most recent call last):\n File \"<python-input-1>\", line 1, in <module>\n class Foo(int, Protocol): ...\nTypeError: Protocols can only inherit from other protocols, got <class 'int'>\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"invalid-raise": {
"title": "detects `raise` statements that raise invalid exceptions or use invalid causes",
"description": "Checks for `raise` statements that raise non-exceptions or use invalid\ncauses for their raised exceptions.\n\n## Why is this bad?\nOnly subclasses or instances of `BaseException` can be raised.\nFor an exception's cause, the same rules apply, except that `None` is also\npermitted. Violating these rules results in a `TypeError` at runtime.\n\n## Examples\n```python\ndef f():\n try:\n something()\n except NameError:\n raise \"oops!\" from f\n\ndef g():\n raise NotImplemented from 42\n```\n\nUse instead:\n```python\ndef f():\n try:\n something()\n except NameError as e:\n raise RuntimeError(\"oops!\") from e\n\ndef g():\n raise NotImplementedError from None\n```\n\n## References\n- [Python documentation: The `raise` statement](https://docs.python.org/3/reference/simple_stmts.html#raise)\n- [Python documentation: Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#built-in-exceptions)",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-return-type": {
"title": "detects returned values that can't be assigned to the function's annotated return type",
"description": "## What it does\nDetects returned values that can't be assigned to the function's annotated return type.\n\n## Why is this bad?\nReturning an object of a type incompatible with the annotated return type may cause confusion to the user calling the function.\n\n## Examples\n```python\ndef func() -> int:\n return \"a\" # error: [invalid-return-type]\n```",
"default": "error",
"oneOf": [
{
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"$ref": "#/definitions/Level"
}
]
},
[red-knot] Support `super` (#17174) ## Summary closes #16615 This PR includes: - Introduces a new type: `Type::BoundSuper` - Implements member lookup for `Type::BoundSuper`, resolving attributes by traversing the MRO starting from the specified class - Adds support for inferring appropriate arguments (`pivot_class` and `owner`) for `super()` when it is used without arguments When `super(..)` appears in code, it can be inferred into one of the following: - `Type::Unknown`: when a runtime error would occur (e.g. calling `super()` out of method scope, or when parameter validation inside `super` fails) - `KnownClass::Super::to_instance()`: when the result is an *unbound super object* or when a dynamic type is used as parameters (MRO traversing is meaningless) - `Type::BoundSuper`: the common case, representing a properly constructed `super` instance that is ready for MRO traversal and attribute resolution ### Terminology Python defines the terms *bound super object* and *unbound super object*. An **unbound super object** is created when `super` is called with only one argument (e.g. `super(A)`). This object may later be bound via the `super.__get__` method. However, this form is rarely used in practice. A **bound super object** is created either by calling `super(pivot_class, owner)` or by using the implicit form `super()`, where both arguments are inferred from the context. This is the most common usage. ### Follow-ups - Add diagnostics for `super()` calls that would result in runtime errors (marked as TODO) - Add property tests for `Type::BoundSuper` ## Test Plan - Added `mdtest/class/super.md` --------- Co-authored-by: Carl Meyer <carl@astral.sh>
2025-04-17 03:41:55 +09:00
"invalid-super-argument": {
"title": "detects invalid arguments for `super()`",
"description": "## What it does\nDetects `super()` calls where:\n- the first argument is not a valid class literal, or\n- the second argument is not an instance or subclass of the first argument.\n\n## Why is this bad?\n`super(type, obj)` expects:\n- the first argument to be a class,\n- and the second argument to satisfy one of the following:\n - `isinstance(obj, type)` is `True`\n - `issubclass(obj, type)` is `True`\n\nViolating this relationship will raise a `TypeError` at runtime.\n\n## Examples\n```python\nclass A:\n ...\nclass B(A):\n ...\n\nsuper(A, B()) # it's okay! `A` satisfies `isinstance(B(), A)`\n\nsuper(A(), B()) # error: `A()` is not a class\n\nsuper(B, A()) # error: `A()` does not satisfy `isinstance(A(), B)`\nsuper(B, A) # error: `A` does not satisfy `issubclass(A, B)`\n```\n\n## References\n- [Python documentation: super()](https://docs.python.org/3/library/functions.html#super)",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"invalid-syntax-in-forward-annotation": {
"title": "detects invalid syntax in forward annotations",
"description": "TODO #14889",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-type-alias-type": {
"title": "detects invalid TypeAliasType definitions",
"description": "## What it does\nChecks for the creation of invalid `TypeAliasType`s\n\n## Why is this bad?\nThere are several requirements that you must follow when creating a `TypeAliasType`.\n\n## Examples\n```python\nfrom typing import TypeAliasType\n\nIntOrStr = TypeAliasType(\"IntOrStr\", int | str) # okay\nNewAlias = TypeAliasType(get_name(), int) # error: TypeAliasType name must be a string literal\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-type-checking-constant": {
"title": "detects invalid `TYPE_CHECKING` constant assignments",
"description": "## What it does\nChecks for a value other than `False` assigned to the `TYPE_CHECKING` variable, or an\nannotation not assignable from `bool`.\n\n## Why is this bad?\nThe name `TYPE_CHECKING` is reserved for a flag that can be used to provide conditional\ncode seen only by the type checker, and not at runtime. Normally this flag is imported from\n`typing` or `typing_extensions`, but it can also be defined locally. If defined locally, it\nmust be assigned the value `False` at runtime; the type checker will consider its value to\nbe `True`. If annotated, it must be annotated as a type that can accept `bool` values.\n\n## Examples\n```python\nTYPE_CHECKING: str\nTYPE_CHECKING = ''\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"invalid-type-form": {
"title": "detects invalid type forms",
"description": "## What it does\nChecks for expressions that are used as [type expressions]\nbut cannot validly be interpreted as such.\n\n## Why is this bad?\nSuch expressions cannot be understood by ty.\nIn some cases, they might raise errors at runtime.\n\n## Examples\n```python\nfrom typing import Annotated\n\na: type[1] # `1` is not a type\nb: Annotated[int] # `Annotated` expects at least two arguments\n```\n[type expressions]: https://typing.python.org/en/latest/spec/annotations.html#type-and-annotation-expressions",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
[ty] Add partial support for `TypeIs` (#18589) ## Summary Part of [#117](https://github.com/astral-sh/ty/issues/117). `TypeIs[]` is a special form that allows users to define their own narrowing functions. Despite the syntax, `TypeIs` is not a generic and, on its own, it is meaningless as a type. [Officially](https://typing.python.org/en/latest/spec/narrowing.html#typeis), a function annotated as returning a `TypeIs[T]` is a <i>type narrowing function</i>, where `T` is called the <i>`TypeIs` return type</i>. A `TypeIs[T]` may or may not be bound to a symbol. Only bound types have narrowing effect: ```python def f(v: object = object()) -> TypeIs[int]: ... a: str = returns_str() if reveal_type(f()): # Unbound: TypeIs[int] reveal_type(a) # str if reveal_type(f(a)): # Bound: TypeIs[a, int] reveal_type(a) # str & int ``` Delayed usages of a bound type has no effect, however: ```python b = f(a) if b: reveal_type(a) # str ``` A `TypeIs[T]` type: * Is fully static when `T` is fully static. * Is a singleton/single-valued when it is bound. * Has exactly two runtime inhabitants when it is unbound: `True` and `False`. In other words, an unbound type have ambiguous truthiness. It is possible to infer more precise truthiness for bound types; however, that is not part of this change. `TypeIs[T]` is a subtype of or otherwise assignable to `bool`. `TypeIs` is invariant with respect to the `TypeIs` return type: `TypeIs[int]` is neither a subtype nor a supertype of `TypeIs[bool]`. When ty sees a function marked as returning `TypeIs[T]`, its `return`s will be checked against `bool` instead. ty will also report such functions if they don't accept a positional argument. Addtionally, a type narrowing function call with no positional arguments (e.g., `f()` in the example above) will be considered invalid. ## Test Plan Markdown tests. --------- Co-authored-by: Carl Meyer <carl@astral.sh>
2025-06-14 05:27:45 +07:00
"invalid-type-guard-call": {
"title": "detects type guard function calls that has no narrowing effect",
"description": "## What it does\nChecks for type guard function calls without a valid target.\n\n## Why is this bad?\nThe first non-keyword non-variadic argument to a type guard function\nis its target and must map to a symbol.\n\nStarred (`is_str(*a)`), literal (`is_str(42)`) and other non-symbol-like\nexpressions are invalid as narrowing targets.\n\n## Examples\n```python\nfrom typing import TypeIs\n\ndef f(v: object) -> TypeIs[int]: ...\n\nf() # Error\nf(*a) # Error\nf(10) # Error\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"invalid-type-guard-definition": {
"title": "detects malformed type guard functions",
"description": "## What it does\nChecks for type guard functions without\na first non-self-like non-keyword-only non-variadic parameter.\n\n## Why is this bad?\nType narrowing functions must accept at least one positional argument\n(non-static methods must accept another in addition to `self`/`cls`).\n\nExtra parameters/arguments are allowed but do not affect narrowing.\n\n## Examples\n```python\nfrom typing import TypeIs\n\ndef f() -> TypeIs[int]: ... # Error, no parameter\ndef f(*, v: object) -> TypeIs[int]: ... # Error, no positional arguments allowed\ndef f(*args: object) -> TypeIs[int]: ... # Error, expect variadic arguments\nclass C:\n def f(self) -> TypeIs[int]: ... # Error, only positional argument expected is `self`\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"invalid-type-variable-constraints": {
"title": "detects invalid type variable constraints",
"description": "## What it does\nChecks for constrained [type variables] with only one constraint.\n\n## Why is this bad?\nA constrained type variable must have at least two constraints.\n\n## Examples\n```python\nfrom typing import TypeVar\n\nT = TypeVar('T', str) # invalid constrained TypeVar\n```\n\nUse instead:\n```python\nT = TypeVar('T', str, int) # valid constrained TypeVar\n# or\nT = TypeVar('T', bound=str) # valid bound TypeVar\n```\n\n[type variables]: https://docs.python.org/3/library/typing.html#typing.TypeVar",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"missing-argument": {
"title": "detects missing required arguments in a call",
"description": "## What it does\nChecks for missing required arguments in a call.\n\n## Why is this bad?\nFailing to provide a required argument will raise a `TypeError` at runtime.\n\n## Examples\n```python\ndef func(x: int): ...\nfunc() # TypeError: func() missing 1 required positional argument: 'x'\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
[ty] validate constructor call of `TypedDict` (#19810) ## Summary Implement validation for `TypedDict` constructor calls and dictionary literal assignments, including support for `total=False` and proper field management. Also add support for `Required` and `NotRequired` type qualifiers in `TypedDict` classes, along with proper inheritance behavior and the `total=` parameter. Support both constructor calls and dict literal syntax part of https://github.com/astral-sh/ty/issues/154 ### Basic Required Field Validation ```py class Person(TypedDict): name: str age: int | None # Error: Missing required field 'name' in TypedDict `Person` constructor incomplete = Person(age=25) # Error: Invalid argument to key "name" with declared type `str` on TypedDict `Person` wrong_type = Person(name=123, age=25) # Error: Invalid key access on TypedDict `Person`: Unknown key "extra" extra_field = Person(name="Bob", age=25, extra=True) ``` <img width="773" height="191" alt="Screenshot 2025-08-07 at 17 59 22" src="https://github.com/user-attachments/assets/79076d98-e85f-4495-93d6-a731aa72a5c9" /> ### Support for `total=False` ```py class OptionalPerson(TypedDict, total=False): name: str age: int | None # All valid - all fields are optional with total=False charlie = OptionalPerson() david = OptionalPerson(name="David") emily = OptionalPerson(age=30) frank = OptionalPerson(name="Frank", age=25) # But type validation and extra fields still apply invalid_type = OptionalPerson(name=123) # Error: Invalid argument type invalid_extra = OptionalPerson(extra=True) # Error: Invalid key access ``` ### Dictionary Literal Validation ```py # Type checking works for both constructors and dict literals person: Person = {"name": "Alice", "age": 30} reveal_type(person["name"]) # revealed: str reveal_type(person["age"]) # revealed: int | None # Error: Invalid key access on TypedDict `Person`: Unknown key "non_existing" reveal_type(person["non_existing"]) # revealed: Unknown ``` ### `Required`, `NotRequired`, `total` ```python from typing import TypedDict from typing_extensions import Required, NotRequired class PartialUser(TypedDict, total=False): name: Required[str] # Required despite total=False age: int # Optional due to total=False email: NotRequired[str] # Explicitly optional (redundant) class User(TypedDict): name: Required[str] # Explicitly required (redundant) age: int # Required due to total=True bio: NotRequired[str] # Optional despite total=True # Valid constructions partial = PartialUser(name="Alice") # name required, age optional full = User(name="Bob", age=25) # name and age required, bio optional # Inheritance maintains original field requirements class Employee(PartialUser): department: str # Required (new field) # name: still Required (inherited) # age: still optional (inherited) emp = Employee(name="Charlie", department="Engineering") # ✅ Employee(department="Engineering") # ❌ e: Employee = {"age": 1} # ❌ ``` <img width="898" height="683" alt="Screenshot 2025-08-11 at 22 02 57" src="https://github.com/user-attachments/assets/4c1b18cd-cb2e-493a-a948-51589d121738" /> ## Implementation The implementation reuses existing validation logic done in https://github.com/astral-sh/ruff/pull/19782 ### ℹ️ Why I did NOT synthesize an `__init__` for `TypedDict`: `TypedDict` inherits `dict.__init__(self, *args, **kwargs)` that accepts all arguments. The type resolution system finds this inherited signature **before** looking for synthesized members. So `own_synthesized_member()` is never called because a signature already exists. To force synthesis, you'd have to override Python’s inheritance mechanism, which would break compatibility with the existing ecosystem. This is why I went with ad-hoc validation. IMO it's the only viable approach that respects Python’s inheritance semantics while providing the required validation. ### Refacto of `Field` **Before:** ```rust struct Field<'db> { declared_ty: Type<'db>, default_ty: Option<Type<'db>>, // NamedTuple and dataclass only init_only: bool, // dataclass only init: bool, // dataclass only is_required: Option<bool>, // TypedDict only } ``` **After:** ```rust struct Field<'db> { declared_ty: Type<'db>, kind: FieldKind<'db>, } enum FieldKind<'db> { NamedTuple { default_ty: Option<Type<'db>> }, Dataclass { default_ty: Option<Type<'db>>, init_only: bool, init: bool }, TypedDict { is_required: bool }, } ``` ## Test Plan Updated Markdown tests --------- Co-authored-by: David Peter <mail@david-peter.de>
2025-08-25 14:45:52 +02:00
"missing-typed-dict-key": {
"title": "detects missing required keys in `TypedDict` constructors",
"description": "## What it does\nDetects missing required keys in `TypedDict` constructor calls.\n\n## Why is this bad?\n`TypedDict` requires all non-optional keys to be provided during construction.\nMissing items can lead to a `KeyError` at runtime.\n\n## Example\n```python\nfrom typing import TypedDict\n\nclass Person(TypedDict):\n name: str\n age: int\n\nalice: Person = {\"name\": \"Alice\"} # missing required key 'age'\n\nalice[\"age\"] # KeyError\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"no-matching-overload": {
"title": "detects calls that do not match any overload",
"description": "## What it does\nChecks for calls to an overloaded function that do not match any of the overloads.\n\n## Why is this bad?\nFailing to provide the correct arguments to one of the overloads will raise a `TypeError`\nat runtime.\n\n## Examples\n```python\n@overload\ndef func(x: int): ...\n@overload\ndef func(x: bool): ...\nfunc(\"string\") # error: [no-matching-overload]\n```",
"default": "error",
"oneOf": [
{
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"$ref": "#/definitions/Level"
}
]
},
"non-subscriptable": {
"title": "detects subscripting objects that do not support subscripting",
"description": "## What it does\nChecks for subscripting objects that do not support subscripting.\n\n## Why is this bad?\nSubscripting an object that does not support it will raise a `TypeError` at runtime.\n\n## Examples\n```python\n4[1] # TypeError: 'int' object is not subscriptable\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"not-iterable": {
"title": "detects iteration over an object that is not iterable",
"description": "## What it does\nChecks for objects that are not iterable but are used in a context that requires them to be.\n\n## Why is this bad?\nIterating over an object that is not iterable will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\nfor i in 34: # TypeError: 'int' object is not iterable\n pass\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"parameter-already-assigned": {
"title": "detects multiple arguments for the same parameter",
"description": "## What it does\nChecks for calls which provide more than one argument for a single parameter.\n\n## Why is this bad?\nProviding multiple values for a single parameter will raise a `TypeError` at runtime.\n\n## Examples\n\n```python\ndef f(x: int) -> int: ...\n\nf(1, x=2) # Error raised here\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"positional-only-parameter-as-kwarg": {
"title": "detects positional-only parameters passed as keyword arguments",
"description": "## What it does\nChecks for keyword arguments in calls that match positional-only parameters of the callable.\n\n## Why is this bad?\nProviding a positional-only parameter as a keyword argument will raise `TypeError` at runtime.\n\n## Example\n\n```python\ndef f(x: int, /) -> int: ...\n\nf(x=1) # Error raised here\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"possibly-missing-attribute": {
"title": "detects references to possibly missing attributes",
"description": "## What it does\nChecks for possibly missing attributes.\n\n## Why is this bad?\nAttempting to access a missing attribute will raise an `AttributeError` at runtime.\n\n## Examples\n```python\nclass A:\n if b:\n c = 0\n\nA.c # AttributeError: type object 'A' has no attribute 'c'\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"possibly-missing-implicit-call": {
"title": "detects implicit calls to possibly missing methods",
"description": "## What it does\nChecks for implicit calls to possibly missing methods.\n\n## Why is this bad?\nExpressions such as `x[y]` and `x * y` call methods\nunder the hood (`__getitem__` and `__mul__` respectively).\nCalling a missing method will raise an `AttributeError` at runtime.\n\n## Examples\n```python\nimport datetime\n\nclass A:\n if datetime.date.today().weekday() != 6:\n def __getitem__(self, v): ...\n\nA()[0] # TypeError: 'A' object is not subscriptable\n```",
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"possibly-missing-import": {
"title": "detects possibly missing imports",
"description": "## What it does\nChecks for imports of symbols that may be missing.\n\n## Why is this bad?\nImporting a missing module or name will raise a `ModuleNotFoundError`\nor `ImportError` at runtime.\n\n## Examples\n```python\n# module.py\nimport datetime\n\nif datetime.date.today().weekday() != 6:\n a = 1\n\n# main.py\nfrom module import a # ImportError: cannot import name 'a' from 'module'\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"possibly-unresolved-reference": {
"title": "detects references to possibly undefined names",
"description": "## What it does\nChecks for references to names that are possibly not defined.\n\n## Why is this bad?\nUsing an undefined variable will raise a `NameError` at runtime.\n\n## Example\n\n```python\nfor i in range(0):\n x = i\n\nprint(x) # NameError: name 'x' is not defined\n```",
"default": "ignore",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"raw-string-type-annotation": {
"title": "detects raw strings in type annotation positions",
"description": "## What it does\nChecks for raw-strings in type annotation positions.\n\n## Why is this bad?\nStatic analysis tools like ty can't analyze type annotations that use raw-string notation.\n\n## Examples\n```python\ndef test(): -> r\"int\":\n ...\n```\n\nUse instead:\n```python\ndef test(): -> \"int\":\n ...\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"redundant-cast": {
"title": "detects redundant `cast` calls",
"description": "## What it does\nDetects redundant `cast` calls where the value already has the target type.\n\n## Why is this bad?\nThese casts have no effect and can be removed.\n\n## Example\n```python\ndef f() -> int:\n return 10\n\ncast(int, f()) # Redundant\n```",
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"static-assert-error": {
"title": "Failed static assertion",
"description": "## What it does\nMakes sure that the argument of `static_assert` is statically known to be true.\n\n## Why is this bad?\nA `static_assert` call represents an explicit request from the user\nfor the type checker to emit an error if the argument cannot be verified\nto evaluate to `True` in a boolean context.\n\n## Examples\n```python\nfrom ty_extensions import static_assert\n\nstatic_assert(1 + 1 == 3) # error: evaluates to `False`\n\nstatic_assert(int(2.0 * 3.0) == 6) # error: does not have a statically known truthiness\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"subclass-of-final-class": {
"title": "detects subclasses of final classes",
"description": "## What it does\nChecks for classes that subclass final classes.\n\n## Why is this bad?\nDecorating a class with `@final` declares to the type checker that it should not be subclassed.\n\n## Example\n\n```python\nfrom typing import final\n\n@final\nclass A: ...\nclass B(A): ... # Error raised here\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"too-many-positional-arguments": {
"title": "detects calls passing too many positional arguments",
"description": "## What it does\nChecks for calls that pass more positional arguments than the callable can accept.\n\n## Why is this bad?\nPassing too many positional arguments will raise `TypeError` at runtime.\n\n## Example\n\n```python\ndef f(): ...\n\nf(\"foo\") # Error raised here\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"type-assertion-failure": {
"title": "detects failed type assertions",
"description": "## What it does\nChecks for `assert_type()` and `assert_never()` calls where the actual type\nis not the same as the asserted type.\n\n## Why is this bad?\n`assert_type()` allows confirming the inferred type of a certain value.\n\n## Example\n\n```python\ndef _(x: int):\n assert_type(x, int) # fine\n assert_type(x, str) # error: Actual type does not match asserted type\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
[red-knot] Support `super` (#17174) ## Summary closes #16615 This PR includes: - Introduces a new type: `Type::BoundSuper` - Implements member lookup for `Type::BoundSuper`, resolving attributes by traversing the MRO starting from the specified class - Adds support for inferring appropriate arguments (`pivot_class` and `owner`) for `super()` when it is used without arguments When `super(..)` appears in code, it can be inferred into one of the following: - `Type::Unknown`: when a runtime error would occur (e.g. calling `super()` out of method scope, or when parameter validation inside `super` fails) - `KnownClass::Super::to_instance()`: when the result is an *unbound super object* or when a dynamic type is used as parameters (MRO traversing is meaningless) - `Type::BoundSuper`: the common case, representing a properly constructed `super` instance that is ready for MRO traversal and attribute resolution ### Terminology Python defines the terms *bound super object* and *unbound super object*. An **unbound super object** is created when `super` is called with only one argument (e.g. `super(A)`). This object may later be bound via the `super.__get__` method. However, this form is rarely used in practice. A **bound super object** is created either by calling `super(pivot_class, owner)` or by using the implicit form `super()`, where both arguments are inferred from the context. This is the most common usage. ### Follow-ups - Add diagnostics for `super()` calls that would result in runtime errors (marked as TODO) - Add property tests for `Type::BoundSuper` ## Test Plan - Added `mdtest/class/super.md` --------- Co-authored-by: Carl Meyer <carl@astral.sh>
2025-04-17 03:41:55 +09:00
"unavailable-implicit-super-arguments": {
"title": "detects invalid `super()` calls where implicit arguments are unavailable.",
"description": "## What it does\nDetects invalid `super()` calls where implicit arguments like the enclosing class or first method argument are unavailable.\n\n## Why is this bad?\nWhen `super()` is used without arguments, Python tries to find two things:\nthe nearest enclosing class and the first argument of the immediately enclosing function (typically self or cls).\nIf either of these is missing, the call will fail at runtime with a `RuntimeError`.\n\n## Examples\n```python\nsuper() # error: no enclosing class or function found\n\ndef func():\n super() # error: no enclosing class or first argument exists\n\nclass A:\n f = super() # error: no enclosing function to provide the first argument\n\n def method(self):\n def nested():\n super() # error: first argument does not exist in this nested function\n\n lambda: super() # error: first argument does not exist in this lambda\n\n (super() for _ in range(10)) # error: argument is not available in generator expression\n\n super() # okay! both enclosing class and first argument are available\n```\n\n## References\n- [Python documentation: super()](https://docs.python.org/3/library/functions.html#super)",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"undefined-reveal": {
"title": "detects usages of `reveal_type` without importing it",
"description": "## What it does\nChecks for calls to `reveal_type` without importing it.\n\n## Why is this bad?\nUsing `reveal_type` without importing it will raise a `NameError` at runtime.\n\n## Examples\n```python\nreveal_type(1) # NameError: name 'reveal_type' is not defined\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unknown-argument": {
"title": "detects unknown keyword arguments in calls",
"description": "## What it does\nChecks for keyword arguments in calls that don't match any parameter of the callable.\n\n## Why is this bad?\nProviding an unknown keyword argument will raise `TypeError` at runtime.\n\n## Example\n\n```python\ndef f(x: int) -> int: ...\n\nf(x=1, y=2) # Error raised here\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unknown-rule": {
2025-05-03 19:49:15 +02:00
"title": "detects `ty: ignore` comments that reference unknown rules",
"description": "## What it does\nChecks for `ty: ignore[code]` where `code` isn't a known lint rule.\n\n## Why is this bad?\nA `ty: ignore[code]` directive with a `code` that doesn't match\nany known rule will not suppress any type errors, and is probably a mistake.\n\n## Examples\n```py\na = 20 / 0 # ty: ignore[division-by-zer]\n```\n\nUse instead:\n\n```py\na = 20 / 0 # ty: ignore[division-by-zero]\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unresolved-attribute": {
"title": "detects references to unresolved attributes",
"description": "## What it does\nChecks for unresolved attributes.\n\n## Why is this bad?\nAccessing an unbound attribute will raise an `AttributeError` at runtime.\nAn unresolved attribute is not guaranteed to exist from the type alone,\nso this could also indicate that the object is not of the type that the user expects.\n\n## Examples\n```python\nclass A: ...\n\nA().foo # AttributeError: 'A' object has no attribute 'foo'\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unresolved-global": {
"title": "detects `global` statements with no definition in the global scope",
"description": "## What it does\nDetects variables declared as `global` in an inner scope that have no explicit\nbindings or declarations in the global scope.\n\n## Why is this bad?\nFunction bodies with `global` statements can run in any order (or not at all), which makes\nit hard for static analysis tools to infer the types of globals without\nexplicit definitions or declarations.\n\n## Example\n```python\ndef f():\n global x # unresolved global\n x = 42\n\ndef g():\n print(x) # unresolved reference\n```\n\nUse instead:\n```python\nx: int\n\ndef f():\n global x\n x = 42\n\ndef g():\n print(x)\n```\n\nOr:\n```python\nx: int | None = None\n\ndef f():\n global x\n x = 42\n\ndef g():\n print(x)\n```",
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"unresolved-import": {
"title": "detects unresolved imports",
"description": "## What it does\nChecks for import statements for which the module cannot be resolved.\n\n## Why is this bad?\nImporting a module that cannot be resolved will raise a `ModuleNotFoundError`\nat runtime.\n\n## Examples\n```python\nimport foo # ModuleNotFoundError: No module named 'foo'\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unresolved-reference": {
"title": "detects references to names that are not defined",
"description": "## What it does\nChecks for references to names that are not defined.\n\n## Why is this bad?\nUsing an undefined variable will raise a `NameError` at runtime.\n\n## Example\n\n```python\nprint(x) # NameError: name 'x' is not defined\n```",
"default": "error",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unsupported-base": {
"title": "detects class bases that are unsupported as ty could not feasibly calculate the class's MRO",
"description": "## What it does\nChecks for class definitions that have bases which are unsupported by ty.\n\n## Why is this bad?\nIf a class has a base that is an instance of a complex type such as a union type,\nty will not be able to resolve the [method resolution order] (MRO) for the class.\nThis will lead to an inferior understanding of your codebase and unpredictable\ntype-checking behavior.\n\n## Examples\n```python\nimport datetime\n\nclass A: ...\nclass B: ...\n\nif datetime.date.today().weekday() != 6:\n C = A\nelse:\n C = B\n\nclass D(C): ... # error: [unsupported-base]\n```\n\n[method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order",
"default": "warn",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unsupported-bool-conversion": {
"title": "detects boolean conversion where the object incorrectly implements `__bool__`",
"description": "## What it does\nChecks for bool conversions where the object doesn't correctly implement `__bool__`.\n\n## Why is this bad?\nIf an exception is raised when you attempt to evaluate the truthiness of an object,\nusing the object in a boolean context will fail at runtime.\n\n## Examples\n\n```python\nclass NotBoolable:\n __bool__ = None\n\nb1 = NotBoolable()\nb2 = NotBoolable()\n\nif b1: # exception raised here\n pass\n\nb1 and b2 # exception raised here\nnot b1 # exception raised here\nb1 < b2 < b1 # exception raised here\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"unsupported-operator": {
"title": "detects binary, unary, or comparison expressions where the operands don't support the operator",
"description": "## What it does\nChecks for binary expressions, comparisons, and unary expressions where\nthe operands don't support the operator.\n\n## Why is this bad?\nAttempting to use an unsupported operator will raise a `TypeError` at\nruntime.\n\n## Examples\n```python\nclass A: ...\n\nA() + A() # TypeError: unsupported operand type(s) for +: 'A' and 'A'\n```",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"unused-ignore-comment": {
"title": "detects unused `type: ignore` comments",
2025-05-03 19:49:15 +02:00
"description": "## What it does\nChecks for `type: ignore` or `ty: ignore` directives that are no longer applicable.\n\n## Why is this bad?\nA `type: ignore` directive that no longer matches any diagnostic violations is likely\nincluded by mistake, and should be removed to avoid confusion.\n\n## Examples\n```py\na = 20 / 2 # ty: ignore[division-by-zero]\n```\n\nUse instead:\n\n```py\na = 20 / 2\n```",
"default": "ignore",
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
},
"zero-stepsize-in-slice": {
"title": "detects a slice step size of zero",
"description": "## What it does\nChecks for step size 0 in slices.\n\n## Why is this bad?\nA slice with a step size of zero will raise a `ValueError` at runtime.\n\n## Examples\n```python\nl = list(range(10))\nl[1:10:0] # ValueError: slice step cannot be zero\n```",
"default": "error",
"oneOf": [
{
"$ref": "#/definitions/Level"
}
]
}
},
"additionalProperties": {
"$ref": "#/definitions/Level"
}
},
"SrcOptions": {
"type": "object",
"properties": {
"exclude": {
"description": "A list of file and directory patterns to exclude from type checking.\n\nPatterns follow a syntax similar to `.gitignore`:\n\n- `./src/` matches only a directory - `./src` matches both files and directories - `src` matches files or directories named `src` - `*` matches any (possibly empty) sequence of characters (except `/`). - `**` matches zero or more path components. This sequence **must** form a single path component, so both `**a` and `b**` are invalid and will result in an error. A sequence of more than two consecutive `*` characters is also invalid. - `?` matches any single character except `/` - `[abc]` matches any character inside the brackets. Character sequences can also specify ranges of characters, as ordered by Unicode, so e.g. `[0-9]` specifies any character between `0` and `9` inclusive. An unclosed bracket is invalid. - `!pattern` negates a pattern (undoes the exclusion of files that would otherwise be excluded)\n\nAll paths are anchored relative to the project root (`src` only matches `<project_root>/src` and not `<project_root>/test/src`). To exclude any directory or file named `src`, use `**/src` instead.\n\nBy default, ty excludes commonly ignored directories:\n\n- `**/.bzr/` - `**/.direnv/` - `**/.eggs/` - `**/.git/` - `**/.git-rewrite/` - `**/.hg/` - `**/.mypy_cache/` - `**/.nox/` - `**/.pants.d/` - `**/.pytype/` - `**/.ruff_cache/` - `**/.svn/` - `**/.tox/` - `**/.venv/` - `**/__pypackages__/` - `**/_build/` - `**/buck-out/` - `**/dist/` - `**/node_modules/` - `**/venv/`\n\nYou can override any default exclude by using a negated pattern. For example, to re-include `dist` use `exclude = [\"!dist\"]`",
"type": [
"array",
"null"
],
"items": {
"type": "string"
}
},
"include": {
"description": "A list of files and directories to check. The `include` option follows a similar syntax to `.gitignore` but reversed: Including a file or directory will make it so that it (and its contents) are type checked.\n\n- `./src/` matches only a directory - `./src` matches both files and directories - `src` matches a file or directory named `src` - `*` matches any (possibly empty) sequence of characters (except `/`). - `**` matches zero or more path components. This sequence **must** form a single path component, so both `**a` and `b**` are invalid and will result in an error. A sequence of more than two consecutive `*` characters is also invalid. - `?` matches any single character except `/` - `[abc]` matches any character inside the brackets. Character sequences can also specify ranges of characters, as ordered by Unicode, so e.g. `[0-9]` specifies any character between `0` and `9` inclusive. An unclosed bracket is invalid.\n\nAll paths are anchored relative to the project root (`src` only matches `<project_root>/src` and not `<project_root>/test/src`).\n\n`exclude` takes precedence over `include`.",
"type": [
"array",
"null"
],
"items": {
"type": "string"
}
},
"respect-ignore-files": {
"description": "Whether to automatically exclude files that are ignored by `.ignore`, `.gitignore`, `.git/info/exclude`, and global `gitignore` files. Enabled by default.",
"type": [
"boolean",
"null"
]
},
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"root": {
"description": "The root of the project, used for finding first-party modules.\n\nIf left unspecified, ty will try to detect common project layouts and initialize `src.root` accordingly:\n\n* if a `./src` directory exists, include `.` and `./src` in the first party search path (src layout or flat) * if a `./<project-name>/<project-name>` directory exists, include `.` and `./<project-name>` in the first party search path * otherwise, default to `.` (flat layout)\n\nBesides, if a `./tests` directory exists and is not a package (i.e. it does not contain an `__init__.py` file), it will also be included in the first party search path.",
"deprecated": true,
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
"type": [
"string",
"null"
]
}
},
"additionalProperties": false
},
"TerminalOptions": {
"type": "object",
"properties": {
"error-on-warning": {
"description": "Use exit code 1 if there are any warning-level diagnostics.\n\nDefaults to `false`.",
"type": [
"boolean",
"null"
]
},
"output-format": {
"description": "The format to use for printing diagnostic messages.\n\nDefaults to `full`.",
"anyOf": [
{
Render Azure, JSON, and JSON lines output with the new diagnostics (#19133) ## Summary This was originally stacked on #19129, but some of the changes I made for JSON also impacted the Azure format, so I went ahead and combined them. The main changes here are: - Implementing `FileResolver` for Ruff's `EmitterContext` - Adding `FileResolver::notebook_index` and `FileResolver::is_notebook` methods - Adding a `DisplayDiagnostics` (with an "s") type for rendering a group of diagnostics at once - Adding `Azure`, `Json`, and `JsonLines` as new `DiagnosticFormat`s I tried a couple of alternatives to the `FileResolver::notebook` methods like passing down the `NotebookIndex` separately and trying to reparse a `Notebook` from Ruff's `SourceFile`. The latter seemed promising, but the `SourceFile` only stores the concatenated plain text of the notebook, not the re-parsable JSON. I guess the current version is just a variation on passing the `NotebookIndex`, but at least we can reuse the existing `resolver` argument. I think a lot of this can be cleaned up once Ruff has its own actual file resolver. As suggested, I also tried deleting the corresponding `Emitter` files in `ruff_linter`, but it doesn't look like git was able to follow this as a rename. It did, however, track that the tests were moved, so the snapshots should be easy to review. ## Test Plan Existing Ruff tests ported to tests in `ruff_db`. I think some other existing ruff tests also cover parts of this refactor. --------- Co-authored-by: Micha Reiser <micha@reiser.io>
2025-07-11 15:04:46 -04:00
"$ref": "#/definitions/OutputFormat"
},
{
"type": "null"
}
]
}
},
"additionalProperties": false
Add knot.toml schema (#15735) ## Summary Adds a JSON schema generation step for Red Knot. This PR doesn't yet add a publishing step because it's still a bit early for that ## Test plan I tested the schema in Zed, VS Code and PyCharm: * PyCharm: You have to manually add a schema mapping (settings JSON Schema Mappings) * Zed and VS code support the inline schema specification ```toml #:schema /Users/micha/astral/ruff/knot.schema.json [environment] extra-paths = [] [rules] call-possibly-unbound-method = "error" unknown-rule = "error" # duplicate-base = "error" ``` ```json { "$schema": "file:///Users/micha/astral/ruff/knot.schema.json", "environment": { "python-version": "3.13", "python-platform": "linux2" }, "rules": { "unknown-rule": "error" } } ``` https://github.com/user-attachments/assets/a18fcd96-7cbe-4110-985b-9f1935584411 The Schema overall works but all editors have their own quirks: * PyCharm: Hovering a name always shows the section description instead of the description of the specific setting. But it's the same for other settings in `pyproject.toml` files 🤷 * VS Code (JSON): Using the generated schema in a JSON file gives exactly the experience I want * VS Code (TOML): * Properties with multiple possible values are repeated during auto-completion without giving any hint how they're different. ![Screen Shot 2025-02-06 at 14 05 35 PM](https://github.com/user-attachments/assets/d7f3c2a9-2351-4226-9fc1-b91aa192a237) * The property description mushes together the description of the property and the value, which looks sort of ridiculous. ![Screen Shot 2025-02-06 at 14 04 40 PM](https://github.com/user-attachments/assets/8b72f04a-c62a-49b5-810f-7ddd472884d0) * Autocompletion and documentation hovering works (except the limitations mentioned above) * Zed: * Very similar to VS Code with the exception that it uses the description attribute to distinguish settings with multiple possible values ![Screen Shot 2025-02-06 at 14 08 19 PM](https://github.com/user-attachments/assets/78a7f849-ff4e-44ff-8317-708eaf02dc1f) I don't think there's much we can do here other than hope (or help) editors improve their auto completion. The same short comings also apply to ruff, so this isn't something new. For now, I think this is good enough
2025-02-07 09:59:40 +00:00
}
}
}