3 Commits

Author	SHA1	Message	Date
Dylan	2a2cc37158	Add t-string fixtures for rules that do not need to be modified (#19146) ... I used a script to attempt to identify those rules with the following property: changing f-strings to t-strings in the corresponding fixture altered the number of lint errors emitted. In other words, those rules for which f-strings and t-strings are not treated the same in the current implementation. This PR documents the subset of such rules where this is fine and no changes need to be made to the implementation of the rule. Mostly these are the rules where it is relevant that an f-string evaluates to type `str` at runtime whereas t-strings do not. In theory many of these fixtures are not super necessary - it's unlikely t-strings would be used for most of these. However, the internal handling of t-strings is tightly coupled with that of f-strings, and may become even more so as we implement the upcoming changes due to https://github.com/python/cpython/pull/135996 . So I'd like to keep these around as regression tests. Note: The `flake8-bandit` fixtures were already added during the original t-string implementation. | Rule(s) | Reason | | --- | --- | | [`unused-method-argument` (`ARG002`)](https://docs.astral.sh/ruff/rules/unused-method-argument/#unused-method-argument-arg002) | f-strings exempted for msg in `NotImplementedError` not relevant for t-strings | | [`logging-f-string` (`G004`)](https://docs.astral.sh/ruff/rules/logging-f-string/#logging-f-string-g004) | t-strings cannot be used here | | [`f-string-in-get-text-func-call` (`INT001`)](https://docs.astral.sh/ruff/rules/f-string-in-get-text-func-call/#f-string-in-get-text-func-call-int001) | rule justified by eager evaluation of interpolations | | [`flake8-bandit`](https://docs.astral.sh/ruff/rules/#flake8-bandit-s)| rules justified by eager evaluation of interpolations | | [`single-string-slots` (`PLC0205`)](https://docs.astral.sh/ruff/rules/single-string-slots/#single-string-slots-plc0205) | t-strings cannot be slots in general | | [`unnecessary-encode-utf8` (`UP012`)](https://docs.astral.sh/ruff/rules/unnecessary-encode-utf8/#unnecessary-encode-utf8-up012) | cannot encode t-strings | | [`no-self-use` (`PLR6301`)](https://docs.astral.sh/ruff/rules/no-self-use/#no-self-use-plr6301) | f-strings exempted for msg in NotImplementedError not relevant for t-strings | | [`pytest-raises-too-broad` (`PT011`)](https://docs.astral.sh/ruff/rules/pytest-raises-too-broad/) / [`pytest-fail-without-message` (`PT016`)](https://docs.astral.sh/ruff/rules/pytest-fail-without-message/#pytest-fail-without-message-pt016) / [`pytest-warns-too-broad` (`PT030`)](https://docs.astral.sh/ruff/rules/pytest-warns-too-broad/#pytest-warns-too-broad-pt030) | t-strings cannot be empty or used as messages | | [`assert-on-string-literal` (`PLW0129`)](https://docs.astral.sh/ruff/rules/assert-on-string-literal/#assert-on-string-literal-plw0129) | t-strings are not strings and cannot be empty | | [`native-literals` (`UP018`)](https://docs.astral.sh/ruff/rules/native-literals/#native-literals-up018) | t-strings are not native literals |	2025-07-14 09:46:31 -05:00
Dhruv Manilawala	b021b5babe	Use `Tokens` from parsed type annotation or parsed source (#11740) ... ## Summary This PR fixes a bug where the checker would require the tokens for an invalid offset w.r.t. the source code. Taking the source code from the linked issue as an example: ```py relese_version :"0.0is 64" ``` Now, this isn't really a valid type annotation but that's what this PR is fixing. Regardless of whether it's valid or not, Ruff shouldn't panic. The checker would visit the parsed type annotation (`0.0is 64`) and try to detect any violations. Certain rule logic requests the tokens for the same but it would fail because the lexer would only have the `String` token considering original source code. This worked before because the lexer was invoked again for each rule logic. The solution is to store the parsed type annotation on the checker if it's in a typing context and use the tokens from that instead if it's available. This is enforced by creating a new API on the checker to get the tokens. But, this means that there are two ways to get the tokens via the checker API. I want to restrict this in a follow-up PR (#11741) to only expose `tokens` and `comment_ranges` as methods and restrict access to the parsed source code. fixes: #11736 ## Test Plan - [x] Add a test case for `F632` rule and update the snapshot - [x] Check all affected rules - [x] No ecosystem changes	2024-06-05 07:50:33 +00:00
Charlie Marsh	5849a75223	Rename `ruff` crate to `ruff_linter` (#7529)	2023-09-20 08:38:27 +02:00