==> Synchronizing chroot copy [/home/alhp/workspace/chroot/root] -> [build_777ac516-2714-4bbe-a702-ea0a74945019]...done ==> Making package: ty 0.0.93-1.1 (Wed Oct 28 16:58:20 2026) ==> Retrieving sources... -> Cloning ty git repo... Cloning into bare repository '/home/alhp/workspace/build/x86-64-v2/ty-0.0.93-1/ty'... -> Cloning ruff git repo... Cloning into bare repository '/home/alhp/workspace/build/x86-64-v2/ty-0.0.93-1/ruff'... ==> Validating source files with b2sums... ty ... Passed ruff ... Skipped Note: in a future version of systemd-nspawn the default set of permitted socket address families will be restricted to AF_INET, AF_INET6 and AF_UNIX. Use --restrict-address-families= to configure the set of permitted socket address families, or set RestrictAddressFamilies= in a .nspawn file. ==> Making package: ty 0.0.93-1.1 (Wed Oct 28 15:59:33 2026) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Installing missing dependencies... resolving dependencies... looking for conflicting packages... Package (16) New Version Net Change Download Size extra/compiler-rt 23.1.4-1 56.19 MiB extra/jemalloc 1:5.4.0-1 1.11 MiB core/libedit 20260512_3.1-1 0.27 MiB extra/libgit2 1:1.9.7-1 3.16 MiB extra/lld 23.1.4-1 7.58 MiB extra/llhttp 9.3.1-1 0.11 MiB extra/llvm-libs 23.1.4-1 164.88 MiB extra/perl-error 0.17031-1 0.04 MiB extra/perl-mailtools 2.22-3 0.10 MiB extra/perl-timedate 2.35-1 0.15 MiB extra/rust 1:1.99.1-1 309.14 MiB extra/zlib-ng 2.3.3-1 0.28 MiB extra/git 2.56.0-1 33.54 MiB extra/maturin 1.15.0-1 24.01 MiB extra/python-installer 1.1.0-1 0.21 MiB extra/uv 0.13.6-1 46.00 MiB 12.33 MiB Total Download Size: 12.33 MiB Total Installed Size: 646.77 MiB :: Proceed with installation? [Y/n] :: Retrieving packages... uv-0.13.6-1-x86_64 downloading... checking keyring... checking package integrity... loading package files... checking for file conflicts... :: Processing package changes... installing perl-error... installing perl-timedate... installing perl-mailtools... installing zlib-ng... installing git... Optional dependencies for git git-zsh-completion: upstream zsh completion tk: gitk and git gui openssh: ssh transport and crypto man: show help with `git command --help` perl-libwww: git svn perl-term-readkey: git svn and interactive.singlekey setting perl-io-socket-ssl: git send-email TLS support perl-authen-sasl: git send-email TLS support perl-cgi: gitweb (web interface) support python: git svn & git p4 [installed] subversion: git svn org.freedesktop.secrets: keyring credential helper libsecret: libsecret credential helper [installed] less: the default pager for git installing compiler-rt... installing llhttp... installing libgit2... installing libedit... installing llvm-libs... installing lld... installing rust... Optional dependencies for rust gdb: rust-gdb script [installed] lldb: rust-lldb script installing maturin... installing python-installer... installing jemalloc... Optional dependencies for jemalloc perl: for jeprof [installed] installing uv... :: Running post-transaction hooks... (1/3) Creating system user accounts... Creating group 'git' with GID 969. Creating user 'git' (git daemon user) with UID 969 and GID 969. (2/3) Reloading system manager configuration... Skipped: Current root is not booted. (3/3) Arming ConditionNeedsUpdate... ==> Retrieving sources... ==> WARNING: Skipping all source file integrity checks. ==> Extracting sources... -> Creating working copy of ty git repo... Cloning into 'ty'... done. Switched to a new branch 'makepkg' -> Creating working copy of ruff git repo... Cloning into 'ruff'... done. Updating files: 16% (1897/11278) Updating files: 17% (1918/11278) Updating files: 18% (2031/11278) Updating files: 19% (2143/11278) Updating files: 20% (2256/11278) Updating files: 21% (2369/11278) Updating files: 22% (2482/11278) Updating files: 23% (2594/11278) Updating files: 24% (2707/11278) Updating files: 25% (2820/11278) Updating files: 26% (2933/11278) Updating files: 26% (2998/11278) Updating files: 27% (3046/11278) Updating files: 28% (3158/11278) Updating files: 29% (3271/11278) Updating files: 30% (3384/11278) Updating files: 31% (3497/11278) Updating files: 32% (3609/11278) Updating files: 33% (3722/11278) Updating files: 34% (3835/11278) Updating files: 35% (3948/11278) Updating files: 36% (4061/11278) Updating files: 37% (4173/11278) Updating files: 38% (4286/11278) Updating files: 39% (4399/11278) Updating files: 40% (4512/11278) Updating files: 41% (4624/11278) Updating files: 42% (4737/11278) Updating files: 43% (4850/11278) Updating files: 44% (4963/11278) Updating files: 45% (5076/11278) Updating files: 46% (5188/11278) Updating files: 47% (5301/11278) Updating files: 48% (5414/11278) Updating files: 49% (5527/11278) Updating files: 50% (5639/11278) Updating files: 51% (5752/11278) Updating files: 52% (5865/11278) Updating files: 53% (5978/11278) Updating files: 54% (6091/11278) Updating files: 55% (6203/11278) Updating files: 56% (6316/11278) Updating files: 57% (6429/11278) Updating files: 58% (6542/11278) Updating files: 59% (6655/11278) Updating files: 60% (6767/11278) Updating files: 61% (6880/11278) Updating files: 62% (6993/11278) Updating files: 63% (7106/11278) Updating files: 64% (7218/11278) Updating files: 65% (7331/11278) Updating files: 65% (7362/11278) Updating files: 66% (7444/11278) Updating files: 67% (7557/11278) Updating files: 68% (7670/11278) Updating files: 69% (7782/11278) Updating files: 70% (7895/11278) Updating files: 71% (8008/11278) Updating files: 72% (8121/11278) Updating files: 73% (8233/11278) Updating files: 74% (8346/11278) Updating files: 75% (8459/11278) Updating files: 76% (8572/11278) Updating files: 77% (8685/11278) Updating files: 78% (8797/11278) Updating files: 79% (8910/11278) Updating files: 79% (8959/11278) Updating files: 79% (9002/11278) Updating files: 80% (9023/11278) Updating files: 81% (9136/11278) Updating files: 82% (9248/11278) Updating files: 83% (9361/11278) Updating files: 84% (9474/11278) Updating files: 85% (9587/11278) Updating files: 86% (9700/11278) Updating files: 87% (9812/11278) Updating files: 88% (9925/11278) Updating files: 88% (9997/11278) Updating files: 89% (10038/11278) Updating files: 90% (10151/11278) Updating files: 91% (10263/11278) Updating files: 92% (10376/11278) Updating files: 93% (10489/11278) Updating files: 94% (10602/11278) Updating files: 95% (10715/11278) Updating files: 96% (10827/11278) Updating files: 97% (10940/11278) Updating files: 98% (11053/11278) Updating files: 98% (11063/11278) Updating files: 99% (11166/11278) Updating files: 100% (11278/11278) Updating files: 100% (11278/11278), done. ==> Starting prepare()... Submodule 'ruff' (https://github.com/astral-sh/ruff) registered for path 'ruff' Cloning into '/startdir/src/ty/ruff'... done. Submodule path 'ruff': checked out '48630fbedd706272d489f81bbcb308b27feb4174' Updating crates.io index Downloading crates ... Downloaded equivalent v1.0.2 Downloaded same-file v1.0.6 Downloaded walkdir v2.5.0 Downloaded crc32fast v1.5.0 Downloaded static_assertions v1.1.0 Downloaded wasm-bindgen-test-shared v0.2.123 Downloaded pkg-config v0.3.32 Downloaded zerofrom-derive v0.1.6 Downloaded utf8_iter v1.0.4 Downloaded ref-cast v1.0.25 Downloaded scopeguard v1.2.0 Downloaded wasm-bindgen-macro v0.2.123 Downloaded futures-core v0.3.32 Downloaded fastrand v2.3.0 Downloaded percent-encoding v2.3.2 Downloaded inotify-sys v0.1.5 Downloaded zerofrom v0.1.6 Downloaded nu-ansi-term v0.50.1 Downloaded autocfg v1.5.0 Downloaded toml_writer v1.1.2+spec-1.1.0 Downloaded ref-cast-impl v1.0.25 Downloaded inventory v0.3.24 Downloaded lazy_static v1.5.0 Downloaded rustc-stable-hash v0.1.2 Downloaded jobserver v0.1.34 Downloaded form_urlencoded v1.2.2 Downloaded unicode-ident v1.0.24 Downloaded wyz v0.5.1 Downloaded quickcheck v1.1.0 Downloaded serde_core v1.0.229 Downloaded dirs-sys v0.5.0 Downloaded funty v2.0.0 Downloaded supports-hyperlinks v3.2.0 Downloaded option-ext v0.2.0 Downloaded wasm-bindgen-shared v0.2.123 Downloaded cfg-if v1.0.4 Downloaded serde_spanned v1.1.1 Downloaded idna_adapter v1.2.1 Downloaded slab v0.4.12 Downloaded attribute-derive-macro v0.10.3 Downloaded hashbrown v0.14.5 Downloaded is-macro v0.3.8 Downloaded get-size-derive2 v0.11.0 Downloaded rustversion v1.0.22 Downloaded pin-project-lite v0.2.16 Downloaded stable_deref_trait v1.2.0 Downloaded oorandom v11.1.5 Downloaded find-msvc-tools v0.1.9 Downloaded toml_datetime v1.1.1+spec-1.1.0 Downloaded heck v0.5.0 Downloaded inotify v0.11.0 Downloaded cc v1.2.65 Downloaded pyproject-toml v0.13.7 Downloaded version-ranges v0.1.1 Downloaded collection_literals v1.0.2 Downloaded errno v0.3.14 Downloaded quote-use v0.8.4 Downloaded matchers v0.2.0 Downloaded proc-macro2 v1.0.107 Downloaded colored v3.1.1 Downloaded tinyvec_macros v0.1.1 Downloaded manyhow-macros v0.11.4 Downloaded quickcheck_macros v1.2.0 Downloaded wild v2.2.1 Downloaded toml v1.1.6+spec-1.1.0 Downloaded dashmap v6.2.1 Downloaded ryu v1.0.20 Downloaded ucd-trie v0.1.7 Downloaded potential_utf v0.1.3 Downloaded pest_derive v2.8.2 Downloaded quote-use-macros v0.8.4 Downloaded wasm-bindgen-futures v0.4.73 Downloaded radium v0.7.0 Downloaded castaway v0.2.4 Downloaded wasm-bindgen-test-macro v0.3.73 Downloaded strum v0.28.0 Downloaded is-terminal v0.4.16 Downloaded typed-arena v2.0.2 Downloaded futures-task v0.3.32 Downloaded itoa v1.0.15 Downloaded notify-types v2.0.0 Downloaded num-traits v0.2.19 Downloaded siphasher v1.0.1 Downloaded utf8-width v0.1.7 Downloaded rayon-core v1.13.0 Downloaded zstd v0.13.3 Downloaded countme v3.0.1 Downloaded smallvec v1.16.1 Downloaded unscanny v0.1.0 Downloaded munge_macro v0.4.7 Downloaded normalize-line-endings v0.3.0 Downloaded get-size2 v0.11.0 Downloaded cast v0.3.0 Downloaded tinystr v0.8.4 Downloaded rustc-hash v2.1.3 Downloaded ptr_meta v0.3.1 Downloaded schemars_derive v1.2.2 Downloaded ctrlc v3.5.2 Downloaded rend v0.5.3 Downloaded dirs v6.0.0 Downloaded test-case-core v3.3.1 Downloaded zmij v1.0.10 Downloaded lock_api v0.4.14 Downloaded thread_local v1.1.9 Downloaded crossbeam v0.8.5 Downloaded jiff-static v0.2.37 Downloaded version_check v0.9.5 Downloaded async-trait v0.1.89 Downloaded shlex v2.0.1 Downloaded pretty_assertions v1.4.1 Downloaded foldhash v0.2.0 Downloaded argfile v1.0.0 Downloaded anstyle-query v1.1.4 Downloaded terminal_size v0.4.4 Downloaded snapbox-macros v1.0.0 Downloaded alloca v0.4.0 Downloaded indoc v2.0.7 Downloaded proc-macro-crate v3.5.0 Downloaded console_log v1.1.0 Downloaded serde_test v1.0.177 Downloaded digest v0.10.7 Downloaded shellexpand v3.1.2 Downloaded strum_macros v0.28.0 Downloaded thiserror-impl v2.0.20 Downloaded yoke-derive v0.8.2 Downloaded tap v1.0.1 Downloaded csv-core v0.1.12 Downloaded imperative v1.0.7 Downloaded tracing-log v0.2.0 Downloaded paste v1.0.15 Downloaded zerovec-derive v0.11.6 Downloaded crypto-common v0.1.6 Downloaded tinytemplate v1.2.1 Downloaded dyn-clone v1.0.20 Downloaded thiserror v2.0.20 Downloaded which v8.0.6 Downloaded proc-macro-utils v0.10.0 Downloaded test-case-macros v3.3.1 Downloaded serde v1.0.229 Downloaded mio v1.0.4 Downloaded diff v0.1.13 Downloaded notify v8.2.0 Downloaded zstd-safe v7.2.4 Downloaded once_cell v1.21.4 Downloaded interpolator v0.5.0 Downloaded attribute-derive v0.10.3 Downloaded path-absolutize v4.0.1 Downloaded ciborium-ll v0.2.2 Downloaded bumpalo v3.19.0 Downloaded salsa-macro-rules v0.28.5 Downloaded proc-macro-error-attr2 v2.0.0 Downloaded serde_derive_internals v0.30.0 Downloaded ptr_meta_derive v0.3.1 Downloaded unit-prefix v0.5.1 Downloaded predicates-core v1.0.10 Downloaded escargot v0.5.15 Downloaded quick-junit v0.8.0 Downloaded quote v1.0.47 Downloaded serde-wasm-bindgen v0.6.5 Downloaded synstructure v0.13.2 Downloaded toml_parser v1.1.3+spec-1.1.0 Downloaded predicates v3.1.4 Downloaded psm v0.1.32 Downloaded toml_datetime v0.7.5+spec-1.1.0 Downloaded utf8parse v0.2.2 Downloaded typed-path v0.12.3 Downloaded etcetera v0.11.0 Downloaded crossbeam-queue v0.3.12 Downloaded libz-rs-sys v0.5.5 Downloaded cpufeatures v0.3.0 Downloaded yoke v0.8.3 Downloaded arrayvec v0.7.8 Downloaded peg-runtime v0.8.5 Downloaded os_str_bytes v7.1.1 Downloaded parking_lot_core v0.9.12 Downloaded os_pipe v1.2.2 Downloaded clap_lex v1.0.0 Downloaded seahash v4.1.0 Downloaded phf v0.11.3 Downloaded rkyv_derive v0.8.18 Downloaded displaydoc v0.2.5 Downloaded wasm-bindgen-test v0.3.73 Downloaded pep440_rs v0.7.3 Downloaded crossbeam-utils v0.8.21 Downloaded cpufeatures v0.2.17 Downloaded phf_shared v0.11.3 Downloaded rancor v0.1.1 Downloaded insta-cmd v0.7.0 Downloaded phf_codegen v0.11.3 Downloaded globwalk v0.9.1 Downloaded datatest-stable v0.3.3 Downloaded matchit v0.9.2 Downloaded anstream v1.0.0 Downloaded anstyle-parse v0.2.7 Downloaded globset v0.4.20 Downloaded libtest-mimic v0.8.1 Downloaded yansi v1.0.1 Downloaded pep508_rs v0.9.2 Downloaded indicatif v0.18.6 Downloaded serde_derive v1.0.229 Downloaded phf v0.14.0 Downloaded assert_fs v1.1.4 Downloaded anstyle-parse v1.0.0 Downloaded test-case v3.3.1 Downloaded is_terminal_polyfill v1.70.1 Downloaded munge v0.4.7 Downloaded condtype v1.3.0 Downloaded anes v0.1.6 Downloaded sha2 v0.10.9 Downloaded thin-vec v0.2.20 Downloaded arc-swap v1.9.2 Downloaded rand_core v0.10.0 Downloaded codspeed-divan-compat v5.0.1 Downloaded litemap v0.8.0 Downloaded tracing-attributes v0.1.31 Downloaded thiserror-impl v1.0.69 Downloaded phf v0.13.1 Downloaded wait-timeout v0.2.1 Downloaded divan-macros v0.1.17 Downloaded crossbeam-channel v0.5.15 Downloaded wasm-bindgen-macro-support v0.2.123 Downloaded either v1.15.0 Downloaded pathdiff v0.2.3 Downloaded bit-set v0.8.0 Downloaded salsa-macros v0.28.5 Downloaded writeable v0.6.4 Downloaded drop_bomb v0.1.5 Downloaded hashbrown v0.17.1 Downloaded phf_shared v0.13.1 Downloaded foldhash v0.1.5 Downloaded fnv v1.0.7 Downloaded peg v0.8.5 Downloaded unicode-id v0.3.6 Downloaded proc-macro-error2 v2.0.1 Downloaded newtype-uuid v1.3.2 Downloaded tempfile v3.27.0 Downloaded generic-array v0.14.7 Downloaded termtree v0.5.1 Downloaded vte v0.15.0 Downloaded minimal-lexical v0.2.1 Downloaded fancy-regex v0.14.0 Downloaded wasm-bindgen v0.2.123 Downloaded chacha20 v0.10.0 Downloaded rand v0.8.8 Downloaded fs-err v3.3.0 Downloaded tracing-indicatif v0.3.14 Downloaded peg-macros v0.8.5 Downloaded typeid v1.0.3 Downloaded anstyle-lossy v1.1.4 Downloaded zip v8.6.0 Downloaded jod-thread v1.0.0 Downloaded cachedir v0.3.1 Downloaded block-buffer v0.10.4 Downloaded allocator-api2 v0.2.21 Downloaded tinyvec v1.10.0 Downloaded pest_generator v2.8.2 Downloaded log v0.4.34 Downloaded hashlink v0.12.0 Downloaded glob v0.3.4 Downloaded urlencoding v2.1.3 Downloaded lsp-server v0.10.0 Downloaded cfg_aliases v0.2.1 Downloaded predicates-tree v1.0.13 Downloaded codspeed-criterion-compat v5.0.1 Downloaded clap_complete_command v0.6.1 Downloaded memchr v2.8.3 Downloaded js-sys v0.3.100 Downloaded colorchoice v1.0.4 Downloaded ciborium v0.2.2 Downloaded icu_provider v2.3.1 Downloaded getrandom v0.4.2 Downloaded insta v1.48.0 Downloaded indexmap v2.14.2 Downloaded strsim v0.11.1 Downloaded flate2 v1.1.2 Downloaded strip-ansi-escapes v0.2.1 Downloaded page_size v0.6.0 Downloaded escape8259 v0.5.3 Downloaded bit-vec v0.8.0 Downloaded libcst_derive v1.9.0 Downloaded codspeed-divan-compat-macros v5.0.1 Downloaded camino v1.2.6 Downloaded rayon v1.12.0 Downloaded phf_codegen v0.14.0 Downloaded snapbox v1.0.0 Downloaded defmt-parser v1.0.0 Downloaded terminfo v0.9.0 Downloaded clap_complete v4.5.58 Downloaded annotate-snippets v0.11.5 Downloaded phf_generator v0.14.0 Downloaded similar v2.7.0 Downloaded tikv-jemallocator v0.6.1 Downloaded toml v0.9.12+spec-1.1.0 Downloaded criterion-plot v0.8.2 Downloaded jiff-core v0.1.0 Downloaded anstyle-svg v0.1.11 Downloaded approx v0.5.1 Downloaded ciborium-io v0.2.2 Downloaded path-dedot v4.0.1 Downloaded char_str v0.0.4 Downloaded bitflags v1.3.2 Downloaded uuid v1.26.1 Downloaded crossbeam-epoch v0.9.18 Downloaded derive-where v1.6.0 Downloaded iana-time-zone v0.1.64 Downloaded path-slash v0.2.1 Downloaded defmt-macros v1.1.0 Downloaded typenum v1.18.0 Downloaded filetime v0.2.29 Downloaded anstream v0.6.21 Downloaded itertools v0.13.0 Downloaded syn v2.0.119 Downloaded clap v4.6.7 Downloaded parking_lot v0.12.5 Downloaded winnow v1.0.0 Downloaded clap_builder v4.6.7 Downloaded bytes v1.12.0 Downloaded serde_json v1.0.151 Downloaded libm v0.2.16 Downloaded futures-util v0.3.32 Downloaded vte v0.14.1 Downloaded codspeed-criterion-compat-walltime v5.0.1 Downloaded html-escape v0.2.13 Downloaded rand v0.10.3 Downloaded tracing-flame v0.2.0 Downloaded imara-diff v0.2.0 Downloaded intrusive-collections v0.10.1 Downloaded dunce v1.0.5 Downloaded difflib v0.4.0 Downloaded bitvec v1.1.1 Downloaded bytecheck v0.8.2 Downloaded manyhow v0.11.4 Downloaded icu_locale_core v2.3.0 Downloaded portable-atomic v1.13.1 Downloaded phf_generator v0.11.3 Downloaded nom v7.1.3 Downloaded criterion v0.8.2 Downloaded natord v1.0.9 Downloaded bytecheck_derive v0.8.2 Downloaded memoffset v0.9.1 Downloaded thiserror v1.0.69 Downloaded rand_core v0.6.4 Downloaded quick-xml v0.41.0 Downloaded simdutf8 v0.1.5 Downloaded pest v2.8.2 Downloaded criterion-plot v0.5.0 Downloaded boxcar v0.2.14 Downloaded anstyle v1.0.14 Downloaded vt100 v0.16.2 Downloaded rkyv v0.8.18 Downloaded ordermap v1.2.2 Downloaded sharded-slab v0.1.7 Downloaded bitflags v2.13.2 Downloaded winnow v0.7.13 Downloaded tracing-core v0.1.36 Downloaded toml_edit v0.25.12+spec-1.1.0 Downloaded syn v3.0.6 Downloaded phf_shared v0.14.0 Downloaded url v2.5.8 Downloaded bstr v1.13.1 Downloaded clap_complete_nushell v4.5.8 Downloaded icu_normalizer_data v2.3.0 Downloaded crossbeam-deque v0.8.6 Downloaded zerotrie v0.2.5 Downloaded console v0.16.4 Downloaded clap_derive v4.6.7 Downloaded anyhow v1.0.104 Downloaded salsa v0.28.5 Downloaded defmt v1.1.0 Downloaded pest_meta v2.8.2 Downloaded icu_collections v2.3.0 Downloaded console_error_panic_hook v0.1.7 Downloaded nix v0.31.2 Downloaded regex-lite v0.1.7 Downloaded stacker v0.1.25 Downloaded web-sys v0.3.100 Downloaded jiff v0.2.37 Downloaded schemars v1.2.2 Downloaded compact_str v0.10.0 Downloaded zstd-sys v2.0.16+zstd.1.5.7 Downloaded libc v0.2.189 Downloaded ignore v0.4.33 Downloaded csv v1.4.0 Downloaded tikv-jemalloc-sys v0.6.1+5.3.0-1-ge13ca993e8ccb9ba9847cc330696e02839f328f7 Downloaded half v2.6.0 Downloaded icu_properties v2.3.0 Downloaded similar v3.2.0 Downloaded ar_archive_writer v0.5.3 Downloaded itertools v0.10.5 Downloaded libcst v1.9.0 Downloaded unicode-normalization v0.1.25 Downloaded zerovec v0.11.8 Downloaded gen-lsp-types v0.11.0 Downloaded codspeed-divan-compat-walltime v5.0.1 Downloaded idna v1.1.0 Downloaded ron v0.12.0 Downloaded itertools v0.15.0 Downloaded regex v1.13.1 Downloaded statrs v0.18.0 Downloaded itertools v0.14.0 Downloaded aho-corasick v1.1.5 Downloaded hashbrown v0.15.5 Downloaded clearscreen v4.0.6 Downloaded zlib-rs v0.5.5 Downloaded icu_properties_data v2.3.0 Downloaded tracing-subscriber v0.3.23 Downloaded markdown v1.0.0 Downloaded chrono v0.4.45 Downloaded unicode-width v0.2.2 Downloaded fern v0.7.1 Downloaded regex-syntax v0.8.11 Downloaded object v0.39.1 Downloaded rustix v1.1.5 Downloaded tracing v0.1.44 Downloaded icu_normalizer v2.3.0 Downloaded regex-automata v0.4.18 Downloaded codspeed v5.0.1 Downloaded rust-stemmers v1.2.0 Downloaded linux-raw-sys v0.12.1 ==> Starting build()... 📦 Including license file `LICENSE` 🍹 Building a mixed python/rust project 🔗 Found bin bindings 📡 Using build options bindings from pyproject.toml Compiling unicode-ident v1.0.24 Compiling proc-macro2 v1.0.107 Compiling quote v1.0.47 Compiling libc v0.2.189 Compiling serde_core v1.0.229 Compiling cfg-if v1.0.4 Compiling memchr v2.8.3 Compiling find-msvc-tools v0.1.9 Compiling shlex v2.0.1 Compiling smallvec v1.16.1 Compiling serde v1.0.229 Compiling autocfg v1.5.0 Compiling zmij v1.0.10 Compiling allocator-api2 v0.2.21 Compiling foldhash v0.2.0 Compiling equivalent v1.0.2 Compiling rustversion v1.0.22 Compiling itoa v1.0.15 Compiling parking_lot_core v0.9.12 Compiling crossbeam-utils v0.8.21 Compiling scopeguard v1.2.0 Compiling heck v0.5.0 Compiling interpolator v0.5.0 Compiling lock_api v0.4.14 Compiling collection_literals v1.0.2 Compiling bitflags v2.13.2 Compiling static_assertions v1.1.0 Compiling siphasher v1.0.1 Compiling stable_deref_trait v1.2.0 Compiling pkg-config v0.3.32 Compiling once_cell v1.21.4 Compiling regex-syntax v0.8.11 Compiling log v0.4.34 Compiling thiserror v2.0.20 Compiling writeable v0.6.4 Compiling pin-project-lite v0.2.16 Compiling litemap v0.8.0 Compiling hashbrown v0.17.1 Compiling portable-atomic v1.13.1 Compiling aho-corasick v1.1.5 Compiling tracing-core v0.1.36 Compiling either v1.15.0 Compiling zstd-safe v7.2.4 Compiling typeid v1.0.3 Compiling utf8_iter v1.0.4 Compiling memoffset v0.9.1 Compiling object v0.39.1 Compiling icu_properties_data v2.3.0 Compiling icu_normalizer_data v2.3.0 Compiling bstr v1.13.1 Compiling phf_shared v0.14.0 Compiling rand_core v0.10.0 Compiling fastrand v2.3.0 Compiling tinyvec_macros v0.1.1 Compiling rustc-hash v2.1.3 Compiling cpufeatures v0.3.0 Compiling tinyvec v1.10.0 Compiling chacha20 v0.10.0 Compiling phf_generator v0.14.0 Compiling hashlink v0.12.0 Compiling itertools v0.15.0 Compiling inventory v0.3.24 Compiling boxcar v0.2.14 Compiling crc32fast v1.5.0 Compiling salsa-macro-rules v0.28.5 Compiling ryu v1.0.20 Compiling rand v0.10.3 Compiling phf_codegen v0.14.0 Compiling anstyle v1.0.14 Compiling seahash v4.1.0 Compiling unicode-normalization v0.1.25 Compiling glob v0.3.4 Compiling intrusive-collections v0.10.1 Compiling num-traits v0.2.19 Compiling arrayvec v0.7.8 Compiling serde_json v1.0.151 Compiling ruff_text_size v0.0.20 (/startdir/src/ty/ruff/crates/ruff_text_size) Compiling ruff_unicode_names2_generator v0.0.20 (/startdir/src/ty/ruff/crates/ruff_unicode_names2_generator) Compiling anyhow v1.0.104 Compiling ruff_source_file v0.0.20 (/startdir/src/ty/ruff/crates/ruff_source_file) Compiling phf v0.14.0 Compiling crossbeam-queue v0.3.12 Compiling crossbeam-epoch v0.9.18 Compiling regex-automata v0.4.18 Compiling syn v2.0.119 Compiling syn v3.0.6 Compiling proc-macro-utils v0.10.0 Compiling castaway v0.2.4 Compiling crossbeam-deque v0.8.6 Compiling jobserver v0.1.34 Compiling iana-time-zone v0.1.64 Compiling unicode-width v0.2.2 Compiling uuid v1.26.1 Compiling drop_bomb v0.1.5 Compiling cc v1.2.65 Compiling percent-encoding v2.3.2 Compiling same-file v1.0.6 Compiling chrono v0.4.45 Compiling walkdir v2.5.0 Compiling form_urlencoded v1.2.2 Compiling vte v0.14.1 Compiling camino v1.2.6 Compiling manyhow-macros v0.11.4 Compiling newtype-uuid v1.3.2 Compiling filetime v0.2.29 Compiling strip-ansi-escapes v0.2.1 Compiling which v8.0.6 Compiling quick-xml v0.41.0 Compiling ruff_unicode_names2 v0.0.20 (/startdir/src/ty/ruff/crates/ruff_unicode_names2) Compiling parking_lot v0.12.5 Compiling ruff_python_trivia v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_trivia) Compiling typed-path v0.12.3 Compiling hashbrown v0.14.5 Compiling ruff_annotate_snippets v0.0.20 (/startdir/src/ty/ruff/crates/ruff_annotate_snippets) Compiling arc-swap v1.9.2 Compiling etcetera v0.11.0 Compiling pathdiff v0.2.3 Compiling matchit v0.9.2 Compiling similar v3.2.0 Compiling path-slash v0.2.1 Compiling supports-hyperlinks v3.2.0 Compiling indexmap v2.14.2 Compiling dunce v1.0.5 Compiling winnow v1.0.0 Compiling dashmap v6.2.1 Compiling serde_spanned v1.1.1 Compiling toml_datetime v1.1.1+spec-1.1.0 Compiling toml_parser v1.1.3+spec-1.1.0 Compiling rustix v1.1.5 Compiling toml_writer v1.1.2+spec-1.1.0 Compiling ar_archive_writer v0.5.3 Compiling radium v0.7.0 Compiling ordermap v1.2.2 Compiling rand_core v0.6.4 Compiling zstd-sys v2.0.16+zstd.1.5.7 Compiling stacker v0.1.25 Compiling toml v1.1.6+spec-1.1.0 Compiling globset v0.4.20 Compiling regex v1.13.1 Compiling utf8parse v0.2.2 Compiling linux-raw-sys v0.12.1 Compiling rayon-core v1.13.0 Compiling tap v1.0.1 Compiling synstructure v0.13.2 Compiling manyhow v0.11.4 Compiling psm v0.1.32 Compiling ignore v0.4.33 Compiling rand v0.8.8 Compiling anstyle-parse v1.0.0 Compiling wyz v0.5.1 Compiling ruff_python_stdlib v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_stdlib) Compiling phf_shared v0.11.3 Compiling option-ext v0.2.0 Compiling is_terminal_polyfill v1.70.1 Compiling colorchoice v1.0.4 Compiling funty v2.0.0 Compiling anstyle-query v1.1.4 Compiling colored v3.1.1 Compiling dirs-sys v0.5.0 Compiling anstream v1.0.0 Compiling inotify-sys v0.1.5 Compiling phf_generator v0.11.3 Compiling crossbeam-channel v0.5.15 Compiling bitvec v1.1.1 Compiling cfg_aliases v0.2.1 Compiling strsim v0.11.1 Compiling clap_lex v1.0.0 Compiling rayon v1.12.0 Compiling nix v0.31.2 Compiling phf_codegen v0.11.3 Compiling inotify v0.11.0 Compiling dirs v6.0.0 Compiling terminal_size v0.4.4 Compiling mio v1.0.4 Compiling fs-err v3.3.0 Compiling clap_builder v4.6.7 Compiling version-ranges v0.1.1 Compiling unscanny v0.1.0 Compiling notify-types v2.0.0 Compiling lazy_static v1.5.0 Compiling sharded-slab v0.1.7 Compiling shellexpand v3.1.2 Compiling terminfo v0.9.0 Compiling crossbeam v0.8.5 Compiling notify v8.2.0 Compiling matchers v0.2.0 Compiling tikv-jemalloc-sys v0.6.1+5.3.0-1-ge13ca993e8ccb9ba9847cc330696e02839f328f7 Compiling thread_local v1.1.9 Compiling nu-ansi-term v0.50.1 Compiling ruff_options_metadata v0.0.20 (/startdir/src/ty/ruff/crates/ruff_options_metadata) Compiling minimal-lexical v0.2.1 Compiling phf v0.11.3 Compiling os_str_bytes v7.1.1 Compiling fnv v1.0.7 Compiling nom v7.1.3 Compiling console v0.16.4 Compiling jiff-core v0.1.0 Compiling ty v0.0.0 (/startdir/src/ty/ruff/crates/ty) Compiling unit-prefix v0.5.1 Compiling jod-thread v1.0.0 Compiling argfile v1.0.0 Compiling wild v2.2.1 Compiling ruff_command_line v0.0.20 (/startdir/src/ty/ruff/crates/ruff_command_line) Compiling indicatif v0.18.6 Compiling serde_derive v1.0.229 Compiling zerovec-derive v0.11.6 Compiling thiserror-impl v2.0.20 Compiling salsa-macros v0.28.5 Compiling ruff_macros v0.0.20 (/startdir/src/ty/ruff/crates/ruff_macros) Compiling clap_derive v4.6.7 Compiling quote-use-macros v0.8.4 Compiling derive-where v1.6.0 Compiling quote-use v0.8.4 Compiling attribute-derive-macro v0.10.3 Compiling zerofrom-derive v0.1.6 Compiling yoke-derive v0.8.2 Compiling displaydoc v0.2.5 Compiling tracing-attributes v0.1.31 Compiling is-macro v0.3.8 Compiling quick-junit v0.8.0 Compiling attribute-derive v0.10.3 Compiling strum_macros v0.28.0 Compiling ctrlc v3.5.2 Compiling clap v4.6.7 Compiling clap_complete v4.5.58 Compiling jiff v0.2.37 Compiling zerofrom v0.1.6 Compiling get-size-derive2 v0.11.0 Compiling clap_complete_nushell v4.5.8 Compiling yoke v0.8.3 Compiling zerovec v0.11.8 Compiling zerotrie v0.2.5 Compiling ty_static v0.0.20 (/startdir/src/ty/ruff/crates/ty_static) Compiling clap_complete_command v0.6.1 Compiling tracing v0.1.44 Compiling tinystr v0.8.4 Compiling potential_utf v0.1.3 Compiling tracing-subscriber v0.3.23 Compiling icu_collections v2.3.0 Compiling icu_locale_core v2.3.0 Compiling strum v0.28.0 Compiling compact_str v0.10.0 Compiling thin-vec v0.2.20 Compiling icu_provider v2.3.1 Compiling pep440_rs v0.7.3 Compiling lsp-server v0.10.0 Compiling get-size2 v0.11.0 Compiling salsa v0.28.5 Compiling icu_properties v2.3.0 Compiling char_str v0.0.4 Compiling icu_normalizer v2.3.0 Compiling ruff_diagnostics v0.0.20 (/startdir/src/ty/ruff/crates/ruff_diagnostics) Compiling ruff_cache v0.0.20 (/startdir/src/ty/ruff/crates/ruff_cache) Compiling idna_adapter v1.2.1 Compiling ruff_notebook v0.0.20 (/startdir/src/ty/ruff/crates/ruff_notebook) Compiling ruff_memory_usage v0.0.20 (/startdir/src/ty/ruff/crates/ruff_memory_usage) Compiling idna v1.1.0 Compiling clearscreen v4.0.6 Compiling tracing-flame v0.2.0 Compiling url v2.5.8 Compiling ruff_python_ast v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_ast) Compiling ruff_index v0.0.20 (/startdir/src/ty/ruff/crates/ruff_index) Compiling gen-lsp-types v0.11.0 Compiling ruff_python_parser v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_parser) Compiling ruff_python_literal v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_literal) Compiling ruff_python_edits v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_edits) Compiling ruff_python_codegen v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_codegen) Compiling ruff_python_importer v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_importer) Compiling zstd v0.13.3 Compiling zip v8.6.0 Compiling tikv-jemallocator v0.6.1 Compiling ty_vendored v0.0.20 (/startdir/src/ty/ruff/crates/ty_vendored) Compiling ruff_db v0.0.20 (/startdir/src/ty/ruff/crates/ruff_db) Compiling ruff_ranged_value v0.0.20 (/startdir/src/ty/ruff/crates/ruff_ranged_value) Compiling ty_site_packages v0.0.20 (/startdir/src/ty/ruff/crates/ty_site_packages) Compiling ty_module_resolver v0.0.20 (/startdir/src/ty/ruff/crates/ty_module_resolver) Compiling ty_combine v0.0.20 (/startdir/src/ty/ruff/crates/ty_combine) Compiling ty_python_core v0.0.20 (/startdir/src/ty/ruff/crates/ty_python_core) Compiling ty_python_semantic v0.0.20 (/startdir/src/ty/ruff/crates/ty_python_semantic) Compiling ty_project v0.0.0 (/startdir/src/ty/ruff/crates/ty_project) Compiling ty_ide v0.0.0 (/startdir/src/ty/ruff/crates/ty_ide) Compiling ty_server v0.0.0 (/startdir/src/ty/ruff/crates/ty_server) Finished `release` profile [optimized + debuginfo] target(s) in 8m 45s 📦 Built wheel to /startdir/src/ty/ruff/target/wheels/ty-0.0.93-py3-none-manylinux_2_39_x86_64.whl ==> Starting check()... Compiling unicode-ident v1.0.24 Compiling proc-macro2 v1.0.107 Compiling quote v1.0.47 Compiling libc v0.2.189 Compiling cfg-if v1.0.4 Compiling serde_core v1.0.229 Compiling memchr v2.8.3 Compiling smallvec v1.16.1 Compiling find-msvc-tools v0.1.9 Compiling shlex v2.0.1 Compiling serde v1.0.229 Compiling autocfg v1.5.0 Compiling zmij v1.0.10 Compiling foldhash v0.2.0 Compiling equivalent v1.0.2 Compiling allocator-api2 v0.2.21 Compiling bitflags v2.13.2 Compiling itoa v1.0.15 Compiling rustversion v1.0.22 Compiling parking_lot_core v0.9.12 Compiling scopeguard v1.2.0 Compiling crossbeam-utils v0.8.21 Compiling collection_literals v1.0.2 Compiling interpolator v0.5.0 Compiling lock_api v0.4.14 Compiling heck v0.5.0 Compiling static_assertions v1.1.0 Compiling siphasher v1.0.1 Compiling once_cell v1.21.4 Compiling stable_deref_trait v1.2.0 Compiling regex-syntax v0.8.11 Compiling pkg-config v0.3.32 Compiling hashbrown v0.17.1 Compiling log v0.4.34 Compiling tracing-core v0.1.36 Compiling pin-project-lite v0.2.16 Compiling litemap v0.8.0 Compiling portable-atomic v1.13.1 Compiling thiserror v2.0.20 Compiling writeable v0.6.4 Compiling zstd-safe v7.2.4 Compiling aho-corasick v1.1.5 Compiling icu_normalizer_data v2.3.0 Compiling utf8_iter v1.0.4 Compiling object v0.39.1 Compiling typeid v1.0.3 Compiling either v1.15.0 Compiling icu_properties_data v2.3.0 Compiling bstr v1.13.1 Compiling phf_shared v0.14.0 Compiling tinyvec_macros v0.1.1 Compiling rustc-hash v2.1.3 Compiling cpufeatures v0.3.0 Compiling rand_core v0.10.0 Compiling fastrand v2.3.0 Compiling chacha20 v0.10.0 Compiling phf_generator v0.14.0 Compiling hashlink v0.12.0 Compiling tinyvec v1.10.0 Compiling syn v2.0.119 Compiling syn v3.0.6 Compiling proc-macro-utils v0.10.0 Compiling crossbeam-queue v0.3.12 Compiling itertools v0.15.0 Compiling ryu v1.0.20 Compiling inventory v0.3.24 Compiling salsa-macro-rules v0.28.5 Compiling crc32fast v1.5.0 Compiling boxcar v0.2.14 Compiling unicode-normalization v0.1.25 Compiling rand v0.10.3 Compiling memoffset v0.9.1 Compiling phf_codegen v0.14.0 Compiling glob v0.3.4 Compiling anstyle v1.0.14 Compiling seahash v4.1.0 Compiling num-traits v0.2.19 Compiling serde_json v1.0.151 Compiling intrusive-collections v0.10.1 Compiling arrayvec v0.7.8 Compiling jobserver v0.1.34 Compiling unicode-width v0.2.2 Compiling crossbeam-epoch v0.9.18 Compiling ruff_unicode_names2_generator v0.0.20 (/startdir/src/ty/ruff/crates/ruff_unicode_names2_generator) Compiling cc v1.2.65 Compiling regex-automata v0.4.18 Compiling filetime v0.2.29 Compiling ruff_text_size v0.0.20 (/startdir/src/ty/ruff/crates/ruff_text_size) Compiling parking_lot v0.12.5 Compiling ruff_source_file v0.0.20 (/startdir/src/ty/ruff/crates/ruff_source_file) Compiling phf v0.14.0 Compiling crossbeam-deque v0.8.6 Compiling castaway v0.2.4 Compiling vte v0.14.1 Compiling anyhow v1.0.104 Compiling iana-time-zone v0.1.64 Compiling indexmap v2.14.2 Compiling manyhow-macros v0.11.4 Compiling strip-ansi-escapes v0.2.1 Compiling same-file v1.0.6 Compiling uuid v1.26.1 Compiling lazy_static v1.5.0 Compiling percent-encoding v2.3.2 Compiling drop_bomb v0.1.5 Compiling sharded-slab v0.1.7 Compiling walkdir v2.5.0 Compiling chrono v0.4.45 Compiling form_urlencoded v1.2.2 Compiling thread_local v1.1.9 Compiling nu-ansi-term v0.50.1 Compiling camino v1.2.6 Compiling ordermap v1.2.2 Compiling ruff_python_trivia v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_trivia) Compiling newtype-uuid v1.3.2 Compiling which v8.0.6 Compiling quick-xml v0.41.0 Compiling hashbrown v0.14.5 Compiling typed-path v0.12.3 Compiling arc-swap v1.9.2 Compiling ruff_annotate_snippets v0.0.20 (/startdir/src/ty/ruff/crates/ruff_annotate_snippets) Compiling etcetera v0.11.0 Compiling supports-hyperlinks v3.2.0 Compiling synstructure v0.13.2 Compiling manyhow v0.11.4 Compiling ar_archive_writer v0.5.3 Compiling dashmap v6.2.1 Compiling pathdiff v0.2.3 Compiling matchit v0.9.2 Compiling dunce v1.0.5 Compiling rustix v1.1.5 Compiling similar v3.2.0 Compiling path-slash v0.2.1 Compiling linux-raw-sys v0.12.1 Compiling winnow v1.0.0 Compiling serde_spanned v1.1.1 Compiling toml_datetime v1.1.1+spec-1.1.0 Compiling regex v1.13.1 Compiling toml_parser v1.1.3+spec-1.1.0 Compiling radium v0.7.0 Compiling toml_writer v1.1.2+spec-1.1.0 Compiling rand_core v0.6.4 Compiling rayon-core v1.13.0 Compiling utf8parse v0.2.2 Compiling tap v1.0.1 Compiling anstyle-parse v1.0.0 Compiling wyz v0.5.1 Compiling ruff_python_stdlib v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_stdlib) Compiling phf_shared v0.11.3 Compiling option-ext v0.2.0 Compiling zstd-sys v2.0.16+zstd.1.5.7 Compiling psm v0.1.32 Compiling stacker v0.1.25 Compiling colorchoice v1.0.4 Compiling anstyle-query v1.1.4 Compiling funty v2.0.0 Compiling is_terminal_polyfill v1.70.1 Compiling colored v3.1.1 Compiling inotify-sys v0.1.5 Compiling crossbeam-channel v0.5.15 Compiling strsim v0.11.1 Compiling ruff_unicode_names2 v0.0.20 (/startdir/src/ty/ruff/crates/ruff_unicode_names2) Compiling clap_lex v1.0.0 Compiling cfg_aliases v0.2.1 Compiling nix v0.31.2 Compiling dirs-sys v0.5.0 Compiling anstream v1.0.0 Compiling rand v0.8.8 Compiling globset v0.4.20 Compiling matchers v0.2.0 Compiling bitvec v1.1.1 Compiling dirs v6.0.0 Compiling toml v1.1.6+spec-1.1.0 Compiling ignore v0.4.33 Compiling phf_generator v0.11.3 Compiling rayon v1.12.0 Compiling inotify v0.11.0 Compiling phf_codegen v0.11.3 Compiling mio v1.0.4 Compiling fs-err v3.3.0 Compiling version-ranges v0.1.1 Compiling unscanny v0.1.0 Compiling notify-types v2.0.0 Compiling terminfo v0.9.0 Compiling shellexpand v3.1.2 Compiling crossbeam v0.8.5 Compiling tikv-jemalloc-sys v0.6.1+5.3.0-1-ge13ca993e8ccb9ba9847cc330696e02839f328f7 Compiling notify v8.2.0 Compiling console v0.16.4 Compiling ruff_options_metadata v0.0.20 (/startdir/src/ty/ruff/crates/ruff_options_metadata) Compiling getrandom v0.4.2 Compiling minimal-lexical v0.2.1 Compiling phf v0.11.3 Compiling os_str_bytes v7.1.1 Compiling fnv v1.0.7 Compiling nom v7.1.3 Compiling argfile v1.0.0 Compiling ty v0.0.0 (/startdir/src/ty/ruff/crates/ty) Compiling jod-thread v1.0.0 Compiling terminal_size v0.4.4 Compiling unit-prefix v0.5.1 Compiling clap_builder v4.6.7 Compiling jiff-core v0.1.0 Compiling tempfile v3.27.0 Compiling indicatif v0.18.6 Compiling ruff_command_line v0.0.20 (/startdir/src/ty/ruff/crates/ruff_command_line) Compiling similar v2.7.0 Compiling wild v2.2.1 Compiling jiff v0.2.37 Compiling ctrlc v3.5.2 Compiling serde_derive v1.0.229 Compiling zerovec-derive v0.11.6 Compiling thiserror-impl v2.0.20 Compiling quote-use-macros v0.8.4 Compiling derive-where v1.6.0 Compiling zerofrom-derive v0.1.6 Compiling quote-use v0.8.4 Compiling attribute-derive-macro v0.10.3 Compiling yoke-derive v0.8.2 Compiling displaydoc v0.2.5 Compiling tracing-attributes v0.1.31 Compiling is-macro v0.3.8 Compiling salsa-macros v0.28.5 Compiling ruff_macros v0.0.20 (/startdir/src/ty/ruff/crates/ruff_macros) Compiling strum_macros v0.28.0 Compiling clap_derive v4.6.7 Compiling quick-junit v0.8.0 Compiling attribute-derive v0.10.3 Compiling clearscreen v4.0.6 Compiling zstd v0.13.3 Compiling clap v4.6.7 Compiling clap_complete v4.5.58 Compiling zip v8.6.0 Compiling clap_complete_nushell v4.5.8 Compiling clap_complete_command v0.6.1 Compiling thin-vec v0.2.20 Compiling compact_str v0.10.0 Compiling lsp-server v0.10.0 Compiling insta v1.48.0 Compiling pep440_rs v0.7.3 Compiling zerofrom v0.1.6 Compiling yoke v0.8.3 Compiling get-size-derive2 v0.11.0 Compiling zerovec v0.11.8 Compiling zerotrie v0.2.5 Compiling tracing v0.1.44 Compiling tracing-subscriber v0.3.23 Compiling insta-cmd v0.7.0 Compiling tinystr v0.8.4 Compiling potential_utf v0.1.3 Compiling icu_collections v2.3.0 Compiling icu_locale_core v2.3.0 Compiling strum v0.28.0 Compiling ty_vendored v0.0.20 (/startdir/src/ty/ruff/crates/ty_vendored) Compiling icu_provider v2.3.1 Compiling tracing-flame v0.2.0 Compiling get-size2 v0.11.0 Compiling icu_normalizer v2.3.0 Compiling icu_properties v2.3.0 Compiling char_str v0.0.4 Compiling ruff_memory_usage v0.0.20 (/startdir/src/ty/ruff/crates/ruff_memory_usage) Compiling ruff_diagnostics v0.0.20 (/startdir/src/ty/ruff/crates/ruff_diagnostics) Compiling ruff_notebook v0.0.20 (/startdir/src/ty/ruff/crates/ruff_notebook) Compiling ruff_cache v0.0.20 (/startdir/src/ty/ruff/crates/ruff_cache) Compiling ty_static v0.0.20 (/startdir/src/ty/ruff/crates/ty_static) Compiling tikv-jemallocator v0.6.1 Compiling idna_adapter v1.2.1 Compiling idna v1.1.0 Compiling url v2.5.8 Compiling gen-lsp-types v0.11.0 Compiling salsa v0.28.5 Compiling ruff_python_ast v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_ast) Compiling ruff_index v0.0.20 (/startdir/src/ty/ruff/crates/ruff_index) Compiling ruff_python_parser v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_parser) Compiling ruff_python_literal v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_literal) Compiling ruff_python_edits v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_edits) Compiling ruff_db v0.0.20 (/startdir/src/ty/ruff/crates/ruff_db) Compiling ruff_python_codegen v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_codegen) Compiling ruff_python_importer v0.0.20 (/startdir/src/ty/ruff/crates/ruff_python_importer) Compiling ruff_ranged_value v0.0.20 (/startdir/src/ty/ruff/crates/ruff_ranged_value) Compiling ty_module_resolver v0.0.20 (/startdir/src/ty/ruff/crates/ty_module_resolver) Compiling ty_site_packages v0.0.20 (/startdir/src/ty/ruff/crates/ty_site_packages) Compiling ty_combine v0.0.20 (/startdir/src/ty/ruff/crates/ty_combine) Compiling ty_python_core v0.0.20 (/startdir/src/ty/ruff/crates/ty_python_core) Compiling ty_python_semantic v0.0.20 (/startdir/src/ty/ruff/crates/ty_python_semantic) Compiling ty_project v0.0.0 (/startdir/src/ty/ruff/crates/ty_project) Compiling ty_ide v0.0.0 (/startdir/src/ty/ruff/crates/ty_ide) Compiling ty_server v0.0.0 (/startdir/src/ty/ruff/crates/ty_server) Finished `test` profile [optimized + debuginfo] target(s) in 9m 16s Running unittests src/lib.rs (ruff/target/debug/deps/ty-0605e068f3d26b0b) running 4 tests test version::tests::version_formatting ... ok test version::tests::version_formatting_with_commits_since_last_tag ... ok test version::tests::version_serializable ... ok test version::tests::version_formatting_with_commit_info ... ok test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 2.41s Running unittests src/main.rs (ruff/target/debug/deps/ty-bb9946f83998ce8e) running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s Running tests/cli/main.rs (ruff/target/debug/deps/cli-1c4a63d38f1886f8) running 220 tests test baseline::update_baseline_conflicts_with_fix ... ok test baseline::update_baseline_requires_path ... ok test check_non_existing_path ... ok test check_file_without_extension_in_subfolder ... ok test baseline::missing_baseline_is_reported ... ok test baseline::update_baseline_does_not_suppress_syntax_errors ... ok test concise_diagnostics ... ok test analysis_options::overrides_precedence ... ok test analysis_options::overrides_basic ... ok test baseline::unsupported_baseline_version_is_reported ... ok test check_file_without_extension ... ok test config_option::cli_config_args_invalid_option ... ok test config_option::invalid_configuration_file ... ok test can_handle_large_binop_expressions ... ok test analysis_options::overrides_inherit_global ... ok test baseline::matches_duplicate_ranges_in_source_order ... ok test config_option::cli_config_args_later_overrides_earlier ... ok test concise_revealed_type ... ok test exit_code::only_info ... ok test exit_code::both_warnings_and_errors_and_exit_zero_on_warning ... ok test baseline::baseline_entries_are_sorted_and_matched_by_file_path ... ok test analysis_options::respect_type_ignore_comments_is_turned_off ... ok test exit_code::only_warnings_and_error_on_warning_overrides_configuration ... ok test baseline::update_baseline_replaces_invalid_json ... ok test exit_code::both_warnings_and_errors ... ok test exit_code::only_warnings ... ok test exit_code::only_warnings_and_exit_zero_on_warning ... ok test exit_code::exit_zero_is_true ... ok test cli_arguments_are_relative_to_the_current_directory ... ok test exit_code::error_on_warning_conflicts_with_exit_zero_on_warning ... ok test config_option::cli_config_args_toml_string_basic ... ok test baseline::update_baseline_is_idempotent ... ok test check_specific_paths ... ok test config_option::cli_config_args_overrides_ty_toml ... ok test baseline::cli_baseline_path ... ok test exit_code::only_warnings_and_error_on_warning_is_disabled_in_configuration ... ok test exit_code::only_info_and_error_on_warning_is_true ... ok test file_selection::exclude_scripts_ignores_scripts_with_invalid_toml ... ok test file_selection::invalid_exclude_pattern ... ok test file_selection::cli_removes_config_exclude ... ok test baseline::ignore_comment_replaces_baseline_entry ... ok test file_selection::invalid_include_pattern_concise_output ... ok test file_selection::exclude_precedence_over_include ... ok test file_selection::configuration_include_no_extension ... ok test config_option::config_file_override ... ok test file_selection::invalid_include_pattern ... ok test file_selection::configuration_include ... ok test file_selection::exclude_argument_precedence_include_argument ... ok test file_selection::force_exclude_directory_outside_project ... ok test baseline::update_and_use_configured_baseline ... ok test file_selection::bazel_symlinked_files ... ok test fixes::fix_clean_file ... ok test file_selection::configuration_exclude ... ok test file_selection::project_directory_brackets_do_not_act_as_glob_syntax ... ok test fixes::add_ignore_unfixable ... ok test fixes::display_only_fix ... ok test file_selection::cli_and_configuration_exclude ... ok Snapshot test passes but the existing value is in a legacy format. Please run `cargo insta test --force-update-snapshots` to update to a newer format. Snapshot contents: x = 1 test fixes::fix_unfixable ... ok test github_diagnostics ... ok test gitlab_empty_diagnostics ... ok test gitlab_diagnostics ... ok test paths_in_configuration_files_are_relative_to_the_project_root ... ok test python_environment::config_file_python_setting_directory_with_no_site_packages ... ok test file_selection::force_exclude_directory_exclusion ... ok Snapshot test passes but the existing value is in a legacy format. Please run `cargo insta test --force-update-snapshots` to update to a newer format. Snapshot contents: x = 1 # ty: ignore[unresolved-reference] y = 2 test fixes::fix_skips_baselined_diagnostics ... ok test python_environment::config_file_python_setting_directory_with_unsupported_python_version ... ok test fixes::add_ignore_keeps_nested_blanket_suppression_used ... ok test file_selection::remove_default_exclude ... ok Snapshot test passes but the existing value is in a legacy format. Please run `cargo insta test --force-update-snapshots` to update to a newer format. Snapshot contents: x: int = 'wrong' print(missing) # ty: ignore[unresolved-reference] test fixes::add_ignore_skips_baselined_diagnostics ... ok test python_environment::config_file_unsupported_python_version ... ok test fixes::fix ... ok test python_environment::config_file_broken_python_setting ... ok test python_environment::cli_unsupported_python_version ... ok test file_selection::exclude_symlink_source_not_target ... ok test python_environment::default_root_flat_layout ... ok test python_environment::default_root_flat_layout_variant ... ok test python_environment::config_file_annotation_showing_where_python_version_set_typing_error ... ok test file_selection::response_files_preserve_literal_at_paths ... ok test fixes::add_ignore ... ok test python_environment::default_root_tests_package ... ok test file_selection::exclude_scripts_only_applies_to_implicitly_discovered_files ... ok test file_selection::explicit_path_overrides_exclude ... ok test python_environment::missing_virtual_env ... ok test python_environment::default_root_python_package ... ok test file_selection::force_exclude_sibling_outside_project_root ... ok test python_environment::default_root_tests_folder ... ok test python_environment::default_root_src_layout ... ok test python_environment::python_argument_points_to_symlinked_executable ... ok test python_environment::config_override_python_platform ... ok test file_selection::exclude_argument ... ok test python_environment::default_root_python_package_pyi ... ok test python_environment::config_file_annotation_showing_where_python_version_set_syntax_error ... ok test python_environment::default_root_project_name_folder ... ok test fixes::unsafe_fix ... ok test python_environment::default_root_python_folder ... ok test python_environment::config_override_python_version ... ok test rule::rule_default_output ... ok test rule::rule_json_output ... ok test rule::rule_unknown ... ok # abstract-and-final-method Default level: error | Stable (since 0.0.64) ## What it does Checks for methods decorated with both `@abstractmethod` and `@final`. ## Why is this bad? An abstract method must be overridden for a subclass to become concrete, but a final method cannot be overridden. Combining the decorators therefore makes it impossible for a subclass to provide a concrete implementation. ## Example ```python from abc import ABC, abstractmethod from typing import final class Base(ABC): @final @abstractmethod def method(self) -> None: ... # error ``` # abstract-method-in-final-class Default level: error | Stable (since 0.0.13) ## What it does Checks for `@final` classes that have unimplemented abstract methods. ## Why is this bad? A class decorated with `@final` cannot be subclassed. If such a class has abstract methods that are not implemented, the class can never be properly instantiated, as the abstract methods can never be implemented (since subclassing is prohibited). At runtime, instantiation of classes with unimplemented abstract methods is only prevented for classes that have `ABCMeta` (or a subclass of it) as their metaclass. However, type checkers also enforce this for classes that do not use `ABCMeta`, since the intent for the class to be abstract is clear from the use of `@abstractmethod`. ## Example ```python from abc import ABC, abstractmethod from typing import final class Base(ABC): @abstractmethod def method(self) -> int: ... @final # `Derived` does not implement `method` class Derived(Base): # error pass ``` # ambiguous-protocol-member Default level: warn | Stable (since 0.0.1-alpha.20) ## What it does Checks for protocol classes with members that will lead to ambiguous interfaces. ## Why is this bad? Assigning to an undeclared variable in a protocol class, or to an undeclared attribute through a protocol method's `self` or `cls` receiver, leads to an ambiguous interface which may lead to the type checker inferring unexpected things. It's recommended to ensure that all members of a protocol class are explicitly declared. ## Examples ```py from typing import ClassVar, Protocol class BaseProto(Protocol): a: int # fine (explicitly declared as `int`) instance_member: str class_member: ClassVar[str] # fine: a method definition using `def` is considered a declaration def method_member(self) -> int: ... def method(self) -> None: self.instance_member = "value" # fine (declared in the class body) self.implicit = "value" # error: [ambiguous-protocol-member] @classmethod def class_method(cls) -> None: cls.class_member = "value" # fine (declared in the class body) cls.implicit_class = "value" # error: [ambiguous-protocol-member] # no explicit declaration, leading to ambiguity c = "some variable" # error # no explicit declaration, leading to ambiguity b = method_member # error # This creates implicit assignments of `d` and `e` in the protocol class body. # Were they really meant to be considered protocol members? # error: "`d` is not declared as a protocol member" # error: "`e` is not declared as a protocol member" for d, e in enumerate(range(42)): pass class SubProto(BaseProto, Protocol): a = 42 # fine (declared in superclass) ``` # assert-type-unspellable-subtype Default level: error | Stable (since 0.0.14) ## What it does Checks for `assert_type()` calls where the actual type is an unspellable subtype of the asserted type. ## Why is this bad? `assert_type()` is intended to ensure that the inferred type of a value is exactly the same as the asserted type. But in some situations, ty has nonstandard extensions to the type system that allow it to infer more precise types than can be expressed in user annotations. ty emits a different error code to `type-assertion-failure` in these situations so that users can easily differentiate between the two cases. ## Example ```toml [environment] python-version = "3.11" ``` ```python from typing import assert_type def _(x: int): assert_type(x, int) # fine if x: # the actual type is `int & ~AlwaysFalsy`, # which excludes types like `Literal[0]` # error: [assert-type-unspellable-subtype] assert_type(x, int) ``` # blanket-ignore-comment Default level: ignore | Stable (since 0.0.57) ## What it does Checks for `ty: ignore` comments that don't specify which rules to ignore. ## Why is this bad? A blanket `ty: ignore` comment suppresses every type-checking diagnostic on the applicable line or file. Specifying rule codes documents which diagnostics are expected and prevents the comment from silencing unrelated errors. ## Examples ```py # error value = unknown # ty: ignore ``` Use instead: ```py value = unknown # ty: ignore[unresolved-reference] ``` # call-abstract-method Default level: error | Stable (since 0.0.16) ## What it does Checks for calls to abstract `@classmethod`s or `@staticmethod`s with "trivial bodies" when accessed on the class object itself. "Trivial bodies" are bodies that solely consist of `...`, `pass`, a docstring, and/or `raise NotImplementedError`. ## Why is this bad? An abstract method with a trivial body has no concrete implementation to execute, so calling such a method directly on the class will probably not have the desired effect. It is also unsound to call these methods directly on the class. Unlike other methods, ty permits abstract methods with trivial bodies to have non-`None` return types even though they always return `None` at runtime. This is because it is expected that these methods will always be overridden rather than being called directly. As a result of this exception to the normal rule, ty may infer an incorrect type if one of these methods is called directly, which may then mean that type errors elsewhere in your code go undetected by ty. Calling abstract classmethods or staticmethods via `type[X]` is allowed, since the actual runtime type could be a concrete subclass with an implementation. ## Example ```python from abc import ABC, abstractmethod class Foo(ABC): @classmethod @abstractmethod def method(cls) -> int: ... # cannot call abstract classmethod Foo.method() # error ``` # call-non-callable Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for calls to non-callable objects. This includes attempts to instantiate classes with unimplemented abstract methods, whether those methods are explicitly decorated with `abstractmethod` or implicitly abstract protocol members. ## Why is this bad? Calling a non-callable object will raise a `TypeError` at runtime. Abstract methods describe behavior that a subclass must implement before it can be instantiated. Classes using `ABCMeta` enforce this at runtime; the type checker also enforces it for classes without `ABCMeta`. ## Examples ```python # TypeError: 'int' object is not callable 4() # error ``` ```python from abc import ABC, abstractmethod class Abstract(ABC): @abstractmethod def method(self) -> int: ... # `method` has not been implemented. Abstract() # error class Concrete(Abstract): def method(self) -> int: return 42 Concrete() # OK ``` # call-top-callable Default level: error | Stable (since 0.0.7) ## What it does Checks for calls to objects typed as `Top[Callable[..., T]]` (the infinite union of all callable types with return type `T`). ## Why is this bad? When `analysis.strict-generic-narrowing` is enabled, `callable(x)` and `isinstance(x, Callable)` narrow an object to `Top[Callable[..., object]]`. We know the object is callable, but we don't know its precise signature. This type represents the set of all possible callable types (including, e.g., functions that take no arguments and functions that require arguments), so no specific set of arguments can be guaranteed to be valid. ## Examples ```toml [analysis] strict-generic-narrowing = true ``` ```python def f(x: object): if callable(x): # We know `x` is callable, but not what arguments it accepts x() # error ``` # conflicting-declarations Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks whether a variable has been declared as two conflicting types. ## Why is this bad A variable with two conflicting declarations likely indicates a mistake. Moreover, it could lead to incorrect or ill-defined type inference for other code that relies on these variables. ## Examples ```python if __name__ == "__main__": a: int else: a: str a = 1 # error ``` # conflicting-metaclass Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for class definitions where the metaclass of the class being created would not be a subclass of the metaclasses of all the class's bases. ## Why is it bad? Such a class definition raises a `TypeError` at runtime. ## Examples ```pyi class M1(type): ... class M2(type): ... class A(metaclass=M1): ... class B(metaclass=M2): ... # TypeError: metaclass conflict class C(A, B): ... # error ``` # cyclic-class-definition Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for class definitions in stub files that inherit (directly or indirectly) from themselves. ## Why is it bad? Although forward references are natively supported in stub files, inheritance cycles are still disallowed, as it is impossible to resolve a consistent [method resolution order] for a class that inherits from itself. ## Examples `foo.pyi`: ```pyi class A(B): ... # error class B(A): ... # error ``` [method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order # cyclic-type-alias-definition Default level: error | Stable (since 0.0.1-alpha.29) ## What it does Checks for circular type alias definitions. ## Why is it bad? Recursive aliases are valid when recursive references occur inside another type, such as `list[Tree]`. An alias cannot expand directly to itself or include itself as a union member. This applies to implicit type aliases, aliases annotated with `TypeAlias`, `type` statements, and aliases created with `TypeAliasType`. ## Examples ```toml [environment] python-version = "3.12" ``` ```python from typing import TypeAlias, TypeAliasType, Union type Itself = Itself # error type A = B # error type B = A # error type IntOr = int | IntOr # error Cycle = TypeAliasType("Cycle", "Cycle") # error LegacyCycle: TypeAlias = "int | LegacyCycle" # error ImplicitCycle = Union[int, "ImplicitCycle"] # error value: ImplicitCycle type Tree = int | list[Tree] # valid recursive alias ``` # dataclass-field-order Default level: error | Stable (since 0.0.15) ## What it does Checks for dataclass definitions where required fields are defined after fields with default values. ## Why is this bad? In dataclasses, all required fields (fields without default values) must be defined before fields with default values. This is a Python requirement that will raise a `TypeError` at runtime if violated. ## Example ```python from dataclasses import dataclass @dataclass class Example: x: int = 1 # Field with default value # Required field after field with default y: str # error ``` # deprecated Default level: warn | Stable (since 0.0.1-alpha.16) ## What it does Checks for uses of deprecated items ## Why is this bad? Deprecated items should no longer be used. ## Examples ```toml [environment] python-version = "3.13" ``` ```python import warnings @warnings.deprecated("use new_func instead") def old_func(): ... old_func() # error: [deprecated] ``` # disjoint-cast Default level: ignore | Stable (since 0.0.78) ## What it does Detects `cast` calls where the inferred type of the value is disjoint from the destination type. Two types are disjoint if they are entirely non-overlapping. For example, `str` and `int` are disjoint types because it is impossible to create a Python object that is both a `str` and an `int` at the same time: Python forbids multiple inheritance between these two classes: ```pycon >>> class StrAndInt(int, str): ... Traceback (most recent call last): File "", line 1, in class StrAndInt(int, str): ... TypeError: multiple bases have instance lay-out conflict ``` This means that any object of type `int` can never also be of type `str`, and any object of type `str` can never also inhabit the type `int`. The only common subtype of these two types is [`Never`][never], the uninhabited type, which has no members. ## Why is this bad? `cast()` is deliberately designed as an "escape hatch" in the type system that is neither validated at runtime nor, by default, by type checkers. While upcasting to a supertype is always sound, and casting to a subtype can be sound in some situations if accompanied by careful validation checks, `cast()` is also deliberately designed to allow unsound narrowing, and most useful applications of `cast()` in real-world code cannot be fully validated by a type checker. Nonetheless, even while acknowledging the fact that `cast()` is intentionally designed to allow unsoundness, casting a value to an entirely *disjoint* type is especially likely to indicate a mistake in your code. A cast from an `int` to a `str`, for example, likely indicates a bug or misunderstanding. This rule therefore provides a means for codebases to partially validate their uses of `cast()` without banning the API -- or even banning all unsound uses of the API -- entirely. ## Example ```py from typing import cast def parse(value: int) -> str: return cast(str, value) # error: [disjoint-cast] ``` Casts between overlapping (non-disjoint) types are allowed: ```py from collections.abc import Sequence from typing import cast def validate(numbers: Sequence[int | None]) -> Sequence[int]: if None in numbers: raise TypeError("must provide a sequence of numbers!") return cast(Sequence[int], numbers) ``` Note that disjointness between types can sometimes be surprising. For example, `list[int]` is disjoint from `list[bool]` even though `bool` is a subtype of `int`. Due to the fact that `list` is [mutable and invariant], it would be deeply unsound for ty to ever narrow an object of type `list[int]` to the type `list[bool]`. As such, ty will complain about a cast from `list[int]` to `list[bool]` when this rule is enabled. Similarly, two `NewType`s can be disjoint even when they share the same underlying nominal base type, unless one `NewType` is explicitly declared as a sub-newtype of the other. ```py from typing import NewType, cast UserId = NewType("UserId", int) ProUserId = NewType("ProUserId", int) def f(x: list[int], user_id: UserId): y = cast(list[bool], x) # error: [disjoint-cast] pro_user_id = cast(ProUserId, user_id) # error: [disjoint-cast] ``` ## Alternatives In many cases, the diagnostic can be avoided by switching to use covariant generic types rather than invariant ones: ```py # `Sequence`, unlike `list`, is immutable and covariant from collections.abc import Sequence from typing import cast def f(x: Sequence[int]): y = cast(Sequence[bool], x) # no diagnostic ``` Though if you're able to use covariant types, a type-safe narrowing mechanism that provides runtime validation, such as using `TypeIs`, is generally preferable to using `cast`: ```py # `Sequence`, unlike `list`, is immutable and covariant from collections.abc import Sequence from typing_extensions import TypeIs, reveal_type def is_sequence_of_bools(x: Sequence[int]) -> TypeIs[Sequence[bool]]: return all(isinstance(item, bool) for item in x) def f(x: Sequence[int]): assert is_sequence_of_bools(x) reveal_type(x) # revealed: Sequence[bool] ``` If you're unable to switch to an immutable, covariant generic type, other solutions to this particular diagnostic might include assigning a new list altogether: ```py def f(x: list[int]): y: list[bool] = [] for item in x: assert isinstance(item, bool) y.append(item) ``` Or using a `TypeGuard`. While the "narrowing" below is still unsound, there is at least some runtime validation of the element types taking place, making it superior to the `cast`: ```py from typing_extensions import TypeGuard, reveal_type def is_list_of_bools(x: list[int]) -> TypeGuard[list[bool]]: return all(isinstance(item, bool) for item in x) def f(x: list[int]): assert is_list_of_bools(x) reveal_type(x) # revealed: list[bool] ``` ## Default level This rule is disabled by default. It is designed as a strict rule for users who want additional soundness checks from their type checker, and it may have false positives in some situations. ## See also - The Ruff rule [`banned-api`][banned-api] can be used to ban the use of `cast()` entirely in your codebase. - `redundant-cast` detects casts where the value already has the destination type. [banned-api]: https://docs.astral.sh/ruff/rules/banned-api/ [mutable and invariant]: https://docs.astral.sh/ty/reference/typing-faq/#invariant-generics [never]: https://docs.python.org/3/library/typing.html#typing.Never # division-by-zero Default level: ignore | Stable (since 0.0.1-alpha.1) ## What it does It detects division by zero. ## Why is this bad? Dividing by zero raises a `ZeroDivisionError` at runtime. ## Rule status This rule is currently disabled by default because of the number of false positives it can produce. ## Examples ```python 5 / 0 # error ``` # duplicate-base Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for class definitions with duplicate bases. ## Why is this bad? Class definitions with duplicate bases raise `TypeError` at runtime. ## Examples ```python class A: ... # TypeError: duplicate base class class B(A, A): ... # error ``` # duplicate-kw-only Default level: error | Stable (since 0.0.1-alpha.12) ## What it does Checks for dataclass definitions with more than one field annotated with `KW_ONLY`. ## Why is this bad? `dataclasses.KW_ONLY` is a special marker used to emulate the `*` syntax in normal signatures. It can only be used once per dataclass. Attempting to annotate two different fields with it will lead to a runtime error. ## Examples ```python from dataclasses import dataclass, KW_ONLY # Crash at runtime @dataclass class A: # error b: int _1: KW_ONLY c: str _2: KW_ONLY d: bytes ``` # dynamic-function-decorator-return Default level: ignore | Stable (since 0.0.73) ## What it does Detects decorator applications that replace a function with `Any` or another [dynamic type]. ## Why is this bad? A decorator can replace the function it receives with any object. Type checkers therefore use the decorator's return type as the type of the decorated function. If the decorator returns `Any` or `Unknown` (explicitly or implicitly), the original type is lost, along with the type checker's ability to catch invalid calls and attribute accesses: ```py def untyped_decorator(function): return function # error: "Decorator returns `Unknown`" @untyped_decorator def stringify(value: int) -> str: return str(value) # No type error is reported, even though `stringify` expects an integer. stringify("not an integer") ``` This rule identifies the point where a decorator erases useful type information, before that imprecision spreads to every use of the decorated function. It can be especially useful in cases where the decorator is defined in a third-party library. Whereas linter rules such as [`ANN201`][ann201] and [`ANN202`][ann202] can complain about missing annotations in your first-party code, they cannot identify instances where unsound types leak into your code due to missing type annotations in third-party code installed into `site-packages`. ## Examples `third_party_library.py`: ```py def untyped_decorator(function): return function ``` `first_party.py`: ```py from third_party_library import untyped_decorator # error: "Decorator returns `Unknown`" @untyped_decorator def greet(name: str) -> str: return f"Hello, {name}!" ``` If making a PR to the third-party library to improve their annotations is not possible, fixes for this diagnostic could include writing your own decorator or introducing a type-safe wrapper: ```py from collections.abc import Callable from typing import TypeVar from third_party_library import untyped_decorator FunctionT = TypeVar("FunctionT", bound=Callable[..., object]) def typed_wrapper(f: FunctionT) -> FunctionT: decorated = untyped_decorator(f) assert decorated is f return decorated @typed_wrapper def greet(name: str) -> str: return f"Hello, {name}!" ``` ## Default level This rule is disabled by default. It is intended for advanced users wanting additional soundness checks from their type checker, not for users who have just started to use type checkers on their Python code. [ann201]: https://docs.astral.sh/ruff/rules/missing-return-type-undocumented-public-function/ [ann202]: https://docs.astral.sh/ruff/rules/missing-return-type-private-function/ [dynamic type]: https://typing.python.org/en/latest/spec/glossary.html#term-dynamic-type # empty-body Default level: error | Stable (since 0.0.14) ## What it does Detects functions with empty bodies that have a non-`None` return type annotation. The errors reported by this rule have the same motivation as the `invalid-return-type` rule. The diagnostic exists as a separate error code to allow users to disable this rule while prototyping code. While we strongly recommend enabling this rule if possible, users migrating from other type checkers may also find it useful to temporarily disable this rule on some or all of their codebase if they find it results in a large number of diagnostics. ## Why is this bad? A function with an empty body (containing only `...`, `pass`, or a docstring) will implicitly return `None` at runtime. Returning `None` when the return type is non-`None` is unsound, and will lead to ty inferring incorrect types elsewhere. Functions with empty bodies are permitted in certain contexts where they serve as declarations rather than implementations: - Functions in stub files (`.pyi`) - Methods in Protocol classes - Abstract methods decorated with `@abstractmethod` - Overload declarations decorated with `@overload` - Functions in `if TYPE_CHECKING` blocks ## Examples ```python def foo() -> int: ... # error: [empty-body] def bar() -> str: # error: [empty-body] """A function that does nothing.""" pass ``` # escape-character-in-forward-annotation Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for forward annotations that contain escape characters. ## Why is this bad? Static analysis tools like ty can't analyze type annotations that contain escape characters. ## Example ```python def foo() -> "intt\b": ... # error ``` # experimental-syntax Default level: warn | Stable (since 0.0.50) ## What it does Checks for experimental syntax that is not part of the Python typing specification. ## Why is this bad? Experimental syntax is specific to ty. It may be rejected by other type checkers and may never be standardized, or be subject to breaking changes. There are also tools and libraries that inspect and/or evaluate type annotations at runtime, including stringized annotations (e.g. Pydantic, typeguard or beartype). Using experimental syntax may lead to runtime errors in this context. Conversely, if you are only using ty as your type checker, and if you are not relying on runtime inspection of type annotations, you can safely ignore this rule. ## Examples ```toml [environment] python-version = "3.14" ``` ```python class A: ... class B: ... def f(value: A & B) -> None: ... # error: [experimental-syntax] def g(value: ~A) -> None: ... # error: [experimental-syntax] ``` # final-on-non-method Default level: error | Stable (since 0.0.20) ## What it does Checks for `@final` decorators applied to non-method functions. ## Why is this bad? The `@final` decorator is only meaningful on methods and classes. Applying it to a module-level function or a nested function has no effect and is likely a mistake. ## Example ```python from typing import final # @final is not allowed on non-method functions @final # error def my_function() -> int: return 0 ``` # final-without-value Default level: error | Stable (since 0.0.15) ## What it does Checks for `Final` symbols that are declared without a value and are never assigned a value in their scope. ## Why is this bad? A `Final` symbol must be initialized with a value at the time of declaration or in a subsequent assignment. At module or function scope, the assignment must occur in the same scope. In a class body, the assignment may occur in `__init__`. Protocol members are declarations of an interface and do not require a value. ## Examples ```python from typing import Final # `Final` symbol without a value MY_CONSTANT: Final[int] # error # OK: `Final` symbol with a value INITIALIZED_CONSTANT: Final[int] = 1 ``` # ignore-comment-unknown-rule Default level: warn | Stable (since 0.0.1-alpha.1) ## What it does Checks for `ty: ignore[code]` or `type: ignore[ty:code]` comments where `code` isn't a known lint rule. ## Why is this bad? A `ty: ignore[code]` or a `type: ignore[ty:code]` directive with a `code` that doesn't match any known rule will not suppress any type errors, and is probably a mistake. ## Examples ```py # error a = 20 / 1 # ty: ignore[division-by-zer] ``` Use instead: ```py a = 20 / 0 # ty: ignore[division-by-zero] ``` # implicit-concatenated-string-type-annotation Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for implicit concatenated strings in type annotation positions. ## Why is this bad? Static analysis tools like ty can't analyze type annotations that use implicit concatenated strings. ## Examples ```python from typing import Literal def test() -> "Literal[" "5" "]": # error return 5 ``` Use instead: ```python from typing import Literal def test() -> "Literal[5]": return 5 ``` # inconsistent-mro Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for classes with an inconsistent [method resolution order] (MRO). ## Why is this bad? Classes with an inconsistent MRO will raise a `TypeError` at runtime. ## Examples ```python class A: ... class B(A): ... # TypeError: Cannot create a consistent method resolution order class C(A, B): ... # error ``` [method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order # index-out-of-bounds Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for attempts to use an out of bounds index to get an item from a container. ## Why is this bad? Using an out of bounds index will raise an `IndexError` at runtime. ## Examples ```python t = (0, 1, 2) # IndexError: tuple index out of range t[3] # error ``` # ineffective-final Default level: warn | Stable (since 0.0.1-alpha.33) ## What it does Checks for calls to `final()` that type checkers cannot interpret. ## Why is this bad? The `final()` function is designed to be used as a decorator. When called directly as a function (e.g., `final(type(...))`), type checkers will not understand the application of `final` and will not prevent subclassing. ## Example ```python from typing import final # Incorrect: type checkers will not prevent subclassing MyClass = final(type("MyClass", (), {})) # error # Correct: use `final` as a decorator @final class MyClass: ... ``` # instance-layout-conflict Default level: error | Stable (since 0.0.1-alpha.12) ## What it does Checks for classes definitions which will fail at runtime due to "instance memory layout conflicts". This error is usually caused by attempting to combine multiple classes that define non-empty `__slots__` in a class's [Method Resolution Order][method-resolution-order] (MRO), or by attempting to combine multiple builtin classes in a class's MRO. ## Why is this bad? Inheriting from bases with conflicting instance memory layouts will lead to a `TypeError` at runtime. An instance memory layout conflict occurs when CPython cannot determine the memory layout instances of a class should have, because the instance memory layout of one of its bases conflicts with the instance memory layout of one or more of its other bases. For example, if a Python class defines non-empty `__slots__`, this will impact the memory layout of instances of that class. Multiple inheritance from more than one different class defining non-empty `__slots__` is not allowed: ```python class A: __slots__ = ("a", "b") class B: __slots__ = ("a", "b") # Even if the values are the same # TypeError: multiple bases have instance lay-out conflict class C(A, B): ... # error ``` An instance layout conflict can also be caused by attempting to use multiple inheritance with two builtin classes, due to the way that these classes are implemented in a CPython C extension: ```python # TypeError: multiple bases have instance lay-out conflict class A(int, float): ... # error ``` Note that pure-Python classes with no `__slots__`, or pure-Python classes with empty `__slots__`, are always compatible: ```python class A: ... class B: __slots__ = () class C: __slots__ = ("a", "b") # fine class D(A, B, C): ... ``` ## Known problems Classes whose `__slots__` values cannot be determined statically are not always considered disjoint bases by ty. Static definitions can include string literals, fixed-length tuples, and literal lists, sets, or dictionaries of string literals. Additionally, this check is not exhaustive: many C extensions (including several in the standard library) define classes that use extended memory layouts and thus cannot coexist in a single MRO. Since it is currently not possible to represent this fact in stub files, having a full knowledge of these classes is also impossible. When it comes to classes that do not define `__slots__` at the Python level, therefore, ty, currently only hard-codes a number of cases where it knows that a class will produce instances with an atypical memory layout. ## Further reading - [CPython documentation: `__slots__`](https://docs.python.org/3/reference/datamodel.html#slots) - [CPython documentation: Method Resolution Order](https://docs.python.org/3/glossary.html#term-method-resolution-order) [method-resolution-order]: https://docs.python.org/3/glossary.html#term-method-resolution-order # invalid-argument-type Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Detects call arguments whose type is not assignable to the corresponding typed parameter. ## Why is this bad? Passing an argument of a type the function (or callable object) does not accept violates the expectations of the function author and may cause unexpected runtime errors within the body of the function. ## Examples ```python def func(x: int): ... func("foo") # error: [invalid-argument-type] ``` # invalid-assignment Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for assignments where the type of the value is not [assignable to] the type of the assignee. ## Why is this bad? Such assignments break the rules of the type system and weaken a type checker's ability to accurately reason about your code. ## Examples ```python a: int = "" # error ``` [assignable to]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable # invalid-attribute-access Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for assignments to class variables from instances and assignments to instance-only attributes from their class. Also checks for reads and writes of generic instance attributes through a generic class or a specialized generic alias. An "instance-only" variable is one which is only ever assigned to or declared when accessed via `self` in an instance method. A generic instance attribute has a type that depends on the class's type parameters. Specializing a generic class does not create separate class attribute storage, so these attributes cannot be accessed through the generic class or a specialized alias. Access through a `type[...]` receiver is allowed because it can refer to a concrete subclass with its own class attributes. ## Why is this bad? Incorrect assignments break the rules of the type system and weaken a type checker's ability to accurately reason about your code. ## Examples ```python from typing import ClassVar class C: instance_var: int class_var: ClassVar[int] = 1 def __init__(self): # instance variable declared in the class body self.instance_var = 42 # instance-only variable not declared in the class body self.instance_only_var: int = 42 C.class_var = 3 # okay C.instance_var = 56 # okay C().instance_var = 72 # okay C().instance_only_var = 100 # okay # Cannot assign to class variable from instance C().class_var = 3 # error # Cannot assign to instance-only variable from class C.instance_only_var = 56 # error ``` ```python from typing import Generic, TypeVar T = TypeVar("T") class Box(Generic[T]): value: T Box[int].value = 1 # error Box.value # error box = Box[int]() box.value = 1 # okay ``` # invalid-attribute-override Default level: error | Stable (since 0.0.33) ## What it does Detects attribute overrides that change whether an inherited attribute is a class variable or an instance variable, expose an incompatible value type, or make a writable attribute read-only. Narrowing a mutable attribute's type is checked separately by the `invalid-mutable-override` rule. Overrides involving properties are checked by `invalid-property-type-override`. ## Why is this bad? Pure class variables and instance variables have different access and assignment behavior. Overriding one with the other violates the [Liskov Substitution Principle][liskov-substitution-principle] ("LSP"), because code that is valid for the superclass may no longer be valid for the subclass. ## Example ```python from typing import ClassVar, Final class Base: instance_attr: int class_attr: ClassVar[int] name: str count: int class Sub(Base): instance_attr: ClassVar[int] # error: [invalid-attribute-override] class_attr: int # error: [invalid-attribute-override] name: bytes # error: [invalid-attribute-override] count: Final[int] = 0 # error: [invalid-attribute-override] ``` Code that reads `Base.name` on an instance expects a string. Code that accepts a `Base` can also assign to `count`; making it final in the subclass removes that operation. [liskov-substitution-principle]: https://en.wikipedia.org/wiki/Liskov_substitution_principle # invalid-await Default level: error | Stable (since 0.0.1-alpha.19) ## What it does Checks for `await` being used with types that are not [Awaitable][awaitable-abc]. ## Why is this bad? Such expressions will lead to `TypeError` being raised at runtime. ## Examples ```python import asyncio class InvalidAwait: def __await__(self) -> int: return 5 async def main() -> None: await InvalidAwait() # error: [invalid-await] await 42 # error: [invalid-await] asyncio.run(main()) ``` [awaitable-abc]: https://docs.python.org/3/library/collections.abc.html#collections.abc.Awaitable # invalid-base Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for class definitions that have bases which are not instances of `type`. ## Why is this bad? Class definitions with bases like this will lead to `TypeError` being raised at runtime. ## Examples ```python class A(42): ... # error: [invalid-base] ``` # invalid-context-manager Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for expressions used in `with` statements that do not implement the context manager protocol. ## Why is this bad? Such a statement will raise `TypeError` at runtime. ## Examples ```python # TypeError: 'int' object does not support the context manager protocol with 1: # error print(2) ``` # invalid-dataclass Default level: error | Stable (since 0.0.12) ## What it does Checks for invalid applications of the `@dataclass` decorator. ## Why is this bad? Applying `@dataclass` with incompatible arguments raises an exception while creating the class: - `order=True` with `eq=False` - `weakref_slot=True` with `slots=False` - `slots=True` when the class already defines `__slots__` Applying `@dataclass` to a class that inherits from `NamedTuple`, `TypedDict`, `Enum`, or `Protocol` is also invalid: - `NamedTuple` and `TypedDict` classes will raise an exception at runtime when instantiating the class. - `Enum` classes with `@dataclass` are [explicitly not supported]. - `Protocol` classes define interfaces and cannot be instantiated. ## Examples ```python from dataclasses import dataclass from typing import NamedTuple @dataclass(order=True, eq=False) # error: [invalid-dataclass] class Ordered: ... @dataclass class Foo(NamedTuple): # error: [invalid-dataclass] x: int ``` See: [explicitly not supported]: https://docs.python.org/3/howto/enum.html#dataclass-support # invalid-dataclass-override Default level: error | Stable (since 0.0.13) ## What it does Checks for dataclass definitions that have both `frozen=True` and a custom `__setattr__` or `__delattr__` method defined. ## Why is this bad? Frozen dataclasses synthesize `__setattr__` and `__delattr__` methods which raise a `FrozenInstanceError` to emulate immutability. Overriding either of these methods raises a runtime error. ## Examples ```python from dataclasses import dataclass @dataclass(frozen=True) class A: def __setattr__(self, name: str, value: object) -> None: ... # error ``` # invalid-declaration Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for declarations where the inferred type of an existing symbol is not [assignable to] its post-hoc declared type. ## Why is this bad? Such declarations break the rules of the type system and weaken a type checker's ability to accurately reason about your code. ## Examples ```python a = 1 a: str # error ``` [assignable to]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable # invalid-enum-member-annotation Default level: warn | Stable (since 0.0.20) ## What it does Checks for enum members that have explicit type annotations. ## Why is this bad? The [typing spec] states that type checkers should infer a literal type for all enum members. An explicit type annotation on an enum member is misleading because the annotated type will be incorrect — the actual runtime type is the enum class itself, not the annotated type. In CPython's `enum` module, annotated assignments with values are still treated as members at runtime, but the annotation will confuse readers of the code. ## Examples ```python from enum import Enum class Pet(Enum): CAT = 1 # OK # enum members should not be annotated DOG: int = 2 # error ``` Use instead: ```python from enum import Enum class Pet(Enum): CAT = 1 DOG = 2 ``` ## References - [Typing spec: Enum members](https://typing.python.org/en/latest/spec/enums.html#enum-members) [typing spec]: https://typing.python.org/en/latest/spec/enums.html#enum-members # invalid-exception-caught Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for exception handlers that catch non-exception classes. ## Why is this bad? Catching classes that do not inherit from `BaseException` will raise a `TypeError` at runtime. ## Example ```python import random def might_raise() -> float: return 1 / random.choice([0, 1, 2, 3, 4, 5]) try: might_raise() except 1: # error ... ``` Use instead: ```python import random def might_raise() -> float: return 1 / random.choice([0, 1, 2, 3, 4, 5]) try: might_raise() except ZeroDivisionError: ... ``` ## References - [Python documentation: except clause](https://docs.python.org/3/reference/compound_stmts.html#except-clause) - [Python documentation: Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#built-in-exceptions) ## Ruff rule This rule corresponds to Ruff's [`except-with-non-exception-classes` (`B030`)](https://docs.astral.sh/ruff/rules/except-with-non-exception-classes) # invalid-explicit-override Default level: error | Stable (since 0.0.1-alpha.28) ## What it does Checks for methods that are decorated with `@override` but do not override any method in a superclass. ## Why is this bad? Decorating a method with `@override` declares to the type checker that the intention is that it should override a method from a superclass. ## Example ```toml [environment] python-version = "3.12" ``` ```python from typing import override class A: @override def foo(self): ... # error class B(A): @override def ffooo(self): ... # error class C: @override def __repr__(self): ... # fine: overrides `object.__repr__` class D(A): @override def foo(self): ... # fine: overrides `A.foo` ``` # invalid-frozen-dataclass-subclass Default level: error | Stable (since 0.0.1-alpha.35) ## What it does Checks for dataclasses with invalid frozen inheritance: - A frozen dataclass cannot inherit from a non-frozen dataclass. - A non-frozen dataclass cannot inherit from a frozen dataclass. ## Why is this bad? Python raises a `TypeError` at runtime when either of these inheritance patterns occurs. ## Example ```python from dataclasses import dataclass @dataclass class Base: x: int @dataclass(frozen=True) class Child(Base): # error y: int @dataclass(frozen=True) class FrozenBase: x: int @dataclass class NonFrozenChild(FrozenBase): # error y: int ``` # invalid-generic-class Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for the creation of invalid generic classes ## Why is this bad? There are several requirements that you must follow when defining a generic class. Many of these result in `TypeError` being raised at runtime if they are violated. ## Examples ```toml [environment] python-version = "3.12" ``` ```python from typing_extensions import Generic, TypeVar T = TypeVar("T") U = TypeVar("U", default=int) # class uses both PEP-695 syntax and legacy syntax class C[U](Generic[T]): ... # error # type parameter with default comes before type parameter without default class D(Generic[U, T]): ... # error ``` ## References - [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction) # invalid-generic-enum Default level: error | Stable (since 0.0.12) ## What it does Checks for enum classes that are also generic. ## Why is this bad? Enum classes cannot be generic. Python does not support generic enums: attempting to create one will either result in an immediate `TypeError` at runtime, or will create a class that cannot be specialized in the way that a normal generic class can. ## Examples ```toml [environment] python-version = "3.12" ``` ```python from enum import Enum from typing import Generic, TypeVar T = TypeVar("T") # enum class cannot be generic (class creation fails with `TypeError`) class E[T](Enum): # error A = 1 # enum class cannot be generic (class creation fails with `TypeError`) class F(Enum, Generic[T]): # error A = 1 # enum class cannot be generic -- the class creation does not immediately fail... class G(Generic[T], Enum): # error A = 1 # ...but this raises `KeyError`: x: G[int] ``` ## References - [Python documentation: Enum](https://docs.python.org/3/library/enum.html) # invalid-ignore-comment Default level: warn | Stable (since 0.0.1-alpha.1) ## What it does Checks for `type: ignore` and `ty: ignore` comments that are syntactically incorrect. ## Why is this bad? A syntactically incorrect ignore comment is probably a mistake and is useless. ## Examples ```py # error a = 20 / 1 # type: ignoree ``` Use instead: ```py a = 20 / 0 # type: ignore ``` # invalid-init-type-variable Default level: error | Stable (since 0.0.83) ## What it does Checks for type variables from outer scopes in an explicit annotation of the `self` parameter of `__init__`. ## Why is this bad? An explicit `self` annotation on `__init__` can determine the type arguments of the constructed class. Referring to type variables bound to the class or an enclosing scope in this annotation can make their meaning ambiguous. The [typing specification](https://typing.python.org/en/latest/spec/constructors.html#init-method) allows type variables scoped to `__init__` instead. ## Example ```toml [environment] python-version = "3.12" ``` ```python class Container[T]: # error: [invalid-init-type-variable] def __init__(self: "Container[list[T]]", value: T) -> None: ... ``` Use a type variable scoped to `__init__` instead: ```python class ListContainer[T]: def __init__[U](self: "ListContainer[list[U]]", value: U) -> None: ... ``` If the receiver annotation does not change the class's type arguments, it can be omitted: ```python class Box[T]: def __init__(self, value: T) -> None: ... ``` This restriction also applies to type variables declared with legacy syntax: ```python from typing import Generic, TypeVar T = TypeVar("T") class LegacyContainer(Generic[T]): # error: [invalid-init-type-variable] def __init__(self: "LegacyContainer[list[T]]", value: T) -> None: ... ``` ## References - [Typing specification: `__init__` method](https://typing.python.org/en/latest/spec/constructors.html#init-method) # invalid-key Default level: error | Stable (since 0.0.1-alpha.17) ## What it does Checks for subscript accesses with invalid keys and `TypedDict` construction with an unknown key. ## Why is this bad? Subscripting with an invalid key will raise a `KeyError` at runtime. Creating a `TypedDict` with an unknown key is likely a mistake; if the `TypedDict` is `closed=true` it also violates the expectations of the type. ## Examples ```python from typing import TypedDict from typing_extensions import NotRequired class Person(TypedDict): name: NotRequired[str] age: NotRequired[int] alice = Person(name="Alice", age=30) # KeyError: 'height' alice["height"] # error # error bob: Person = {"nickname": "Bob", "age": 30} # typo! # error carol = Person(name="Carol", aeg=25) # typo! ``` # invalid-legacy-positional-parameter Default level: ignore | Stable (since 0.0.15) ## What it does Checks for parameters that appear to be attempting to use the legacy convention to specify that a parameter is positional-only, but do so incorrectly. The "legacy convention" for specifying positional-only parameters was specified in [PEP 484][pep-484]. It states that parameters with names starting with `__` should be considered positional-only by type checkers. [PEP 570][pep-570], introduced in Python 3.8, added dedicated syntax for specifying positional-only parameters, rendering the legacy convention obsolete. However, some codebases may still use the legacy convention for compatibility with older Python versions. This rule is disabled by default because modern code may use `__`-prefixed parameter names for other purposes. Enable it if your codebase uses the legacy convention and you want to check that it is applied consistently. ## Why is this bad? In most cases, a type checker will not consider a parameter to be positional-only if it comes after a positional-or-keyword parameter, even if its name starts with `__`. This may be unexpected if the author intended to use the legacy convention. ## Example ```python # `__y` is not considered positional-only def f(x, __y): # error pass ``` Use instead: ```python def f(__x, __y): # If you need compatibility with Python <=3.7 pass ``` or: ```python def f(x, y, /): # Python 3.8+ syntax pass ``` ## References - [Typing spec: positional-only parameters (legacy syntax)](https://typing.python.org/en/latest/spec/historical.html#pos-only-double-underscore) - [Python glossary: parameters](https://docs.python.org/3/glossary.html#term-parameter) [pep-484]: https://peps.python.org/pep-0484/#positional-only-arguments [pep-570]: https://peps.python.org/pep-0570/ # invalid-legacy-type-variable Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for the creation of invalid legacy `TypeVar`s ## Why is this bad? There are several requirements that you must follow when creating a legacy `TypeVar`. ## Examples ```python from typing import TypeVar T = TypeVar("T") # okay T = TypeVar("T") # error: "Cannot redefine `T` as a type variable" # TypeVar must be immediately assigned to a variable # error def f(t: TypeVar("U")): ... # ty: ignore[invalid-type-form] ``` ## References - [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction) # invalid-match-pattern Default level: error | Stable (since 0.0.18) ## What it does Checks for invalid match patterns. ## Why is this bad? Invalid match patterns can cause a `TypeError` at runtime. This includes: - Using a non-type object in a class pattern. - Providing positional subpatterns when `__match_args__` is missing or has an invalid static type. - Matching against `collections.abc.Callable` with positional subpatterns. - Matching against a non-runtime-checkable protocol. - Matching against a `TypedDict`. ## Examples ```python class Point: __match_args__ = ("x", "y") def describe(p: Point) -> None: match p: # TypeError at runtime: Point() accepts 2 positional sub-patterns (3 given) case Point(x, y, z): # error: [invalid-match-pattern] ... ``` ```python NotAClass = 42 match object(): # TypeError at runtime: called match pattern must be a class case NotAClass(): # error: [invalid-match-pattern] ... ``` # invalid-metaclass Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for arguments to `metaclass=` that are invalid. ## Why is this bad? Python allows arbitrary expressions to be used as the argument to `metaclass=`. These expressions, however, need to be callable and accept the same arguments as `type.__new__`. ## Example ```python # TypeError: 'int' object is not callable class B(metaclass=42): ... # error ``` ## References - [Python documentation: Metaclasses](https://docs.python.org/3/reference/datamodel.html#metaclasses) # invalid-method-override Default level: error | Stable (since 0.0.1-alpha.20) ## What it does Detects method overrides that violate the [Liskov Substitution Principle][liskov-substitution-principle] ("LSP"). The LSP states that an instance of a subtype should be substitutable for an instance of its supertype. Applied to Python, this means: 1. All argument combinations a superclass method accepts must also be accepted by an overriding subclass method. 1. The return type of an overriding subclass method must be a subtype of the return type of the superclass method. ## Why is this bad? Violating the Liskov Substitution Principle will lead to many of ty's assumptions and inferences being incorrect, which will mean that it will fail to catch many possible type errors in your code. ## Example ```python class Super: def method(self, x) -> int: return 42 class Sub(Super): # Liskov violation: `str` is not a subtype of `int`, # but the supertype method promises to return an `int`. def method(self, x) -> str: # error: [invalid-method-override] return "foo" def accepts_super(s: Super) -> int: return s.method(x=42) # The result of this call is a string, but ty will infer it to be an `int` # due to the violation of the Liskov Substitution Principle. accepts_super(Sub()) class Sub2(Super): # Liskov violation: the superclass method can be called with a `x=` # keyword argument, but the subclass method does not accept it. def method(self, y) -> int: # error: [invalid-method-override] return 42 # TypeError at runtime: method() got an unexpected keyword argument 'x' # ty cannot catch this error due to the violation of the Liskov Substitution Principle. accepts_super(Sub2()) ``` ## Common issues ### Why does ty complain about my `__eq__` method? `__eq__` and `__ne__` methods in Python are generally expected to accept arbitrary objects as their second argument, for example: ```python class A: x: int def __eq__(self, other: object) -> bool: # gracefully handle an object of an unexpected type # without raising an exception if not isinstance(other, A): return False return self.x == other.x ``` If `A.__eq__` here were annotated as only accepting `A` instances for its second argument, it would imply that you wouldn't be able to use `==` between instances of `A` and instances of unrelated classes without an exception possibly being raised. While some classes in Python do indeed behave this way, the strongly held convention is that it should be avoided wherever possible. As part of this check, therefore, ty enforces that `__eq__` and `__ne__` methods accept `object` as their second argument. ### Why does ty disagree with Ruff about how to write my method? Ruff has several rules that will encourage you to rename a parameter, or change its type signature, if it thinks you're falling into a certain anti-pattern. For example, Ruff's [ARG002](https://docs.astral.sh/ruff/rules/unused-method-argument/) rule recommends that an unused parameter should either be removed or renamed to start with `_`. Applying either of these suggestions can cause ty to start reporting an `invalid-method-override` error if the function in question is a method on a subclass that overrides a method on a superclass, and the change would cause the subclass method to no longer accept all argument combinations that the superclass method accepts. This can usually be resolved by adding [`@typing.override`][override] to your method definition. Ruff knows that a method decorated with `@typing.override` is intended to override a method by the same name on a superclass, and avoids reporting rules like ARG002 for such methods; it knows that the changes recommended by ARG002 would violate the Liskov Substitution Principle. Correct use of `@override` is enforced by ty's `invalid-explicit-override` rule. [liskov-substitution-principle]: https://en.wikipedia.org/wiki/Liskov_substitution_principle [override]: https://docs.python.org/3/library/typing.html#typing.override # invalid-module-getattr-call Default level: error | Stable (since 0.0.72) ## What it does Checks for imports that fail when calling a module-level `__getattr__` function. ## Why is this bad? If a module defines `__getattr__`, Python calls it when a `from` import requests a name that is not otherwise defined. The import raises an exception if `__getattr__` cannot accept the requested name. ## Examples `module.py`: ```python def __getattr__() -> str: return "fallback" ``` `main.py`: ```python # TypeError: __getattr__() takes 0 positional arguments but 1 was given from module import missing # error ``` # invalid-mutable-override Default level: error | Stable (since 0.0.81) ## What it does Detects overrides that narrow the type of a writable attribute. ## Why is this bad? A subclass must accept every write allowed by the superclass. Narrowing a mutable attribute's type allows code using the superclass interface to invalidate the subclass's attribute type. ## Example ```python class Base: value: int class Child(Base): value: bool # error: [invalid-mutable-override] def reset(obj: Base) -> None: obj.value = 42 reset(Child()) # The value is no longer a bool. ``` Use the same annotation in both classes, or expose a read-only property if callers do not need to write the attribute. # invalid-named-tuple Default level: error | Stable (since 0.0.1-alpha.19) ## What it does Checks for invalidly defined `NamedTuple` classes. ## Why is this bad? An invalidly defined `NamedTuple` class may lead to the type checker drawing incorrect conclusions. It may also lead to `TypeError`s or `AttributeError`s at runtime. ## Examples A class definition cannot combine `NamedTuple` with other base classes in multiple inheritance; doing so raises a `TypeError` at runtime. The sole exception to this rule is `Generic[]`, which can be used alongside `NamedTuple` in a class's bases list. ```pycon >>> from typing import NamedTuple >>> class Foo(NamedTuple, object): ... TypeError: can only inherit from a NamedTuple type and Generic ``` Further, `NamedTuple` field names cannot start with an underscore: ```pycon >>> from typing import NamedTuple >>> class Foo(NamedTuple): ... _bar: int ValueError: Field names cannot start with an underscore: '_bar' ``` `NamedTuple` classes also have certain synthesized attributes (like `_asdict`, `_make`, `_replace`, etc.) that cannot be overwritten. Attempting to assign to these attributes without a type annotation will raise an `AttributeError` at runtime. ```pycon >>> from typing import NamedTuple >>> class Foo(NamedTuple): ... x: int ... _asdict = 42 AttributeError: Cannot overwrite NamedTuple attribute _asdict ``` Finally, `NamedTuple` field annotations cannot use the `ClassVar` or `Final` type qualifiers. These qualifiers also cause a runtime error when annotations are evaluated eagerly: ```pycon >>> from typing import ClassVar, NamedTuple >>> class Foo(NamedTuple): ... x: ClassVar[int] TypeError: typing.ClassVar[int] is not valid as type argument ``` # invalid-named-tuple-override Default level: warn | Stable (since 0.0.31) ## What it does Checks for subclass members that override inherited `NamedTuple` fields. ## Why is this bad? Reusing an inherited `NamedTuple` field name in a subclass creates a class where tuple indexing and `repr()` still reflect the original field, while attribute access follows the subclass member. ## Default level This rule is a warning by default because these overrides do not make the class invalid at runtime. ## Examples ```python from typing import NamedTuple class User(NamedTuple): name: str class Admin(User): name = "shadowed" # error: [invalid-named-tuple-override] admin = Admin("Alice") admin.name # "shadowed" admin[0] # "Alice" ``` # invalid-newtype Default level: error | Stable (since 0.0.1-alpha.27) ## What it does Checks for the creation of invalid `NewType`s ## Why is this bad? There are several requirements that you must follow when creating a `NewType`. ## Examples ```python from typing import NewType def get_name() -> str: return "name" Foo = NewType("Foo", int) # okay # The first argument to `NewType` must be a string literal Bar = NewType(get_name(), int) # error # invalid base for `typing.NewType` Baz = NewType("Baz", int | str) # error ``` # invalid-overload Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for various invalid `@overload` usages. ## Why is this bad? The `@overload` decorator is used to define functions and methods that accepts different combinations of arguments and return different types based on the arguments passed. This is mainly beneficial for type checkers. But, if the `@overload` usage is invalid, the type checker may not be able to provide correct type information. ## Examples ### Single overload ```py from typing import overload @overload def foo(x: int) -> int: ... # error def foo(x: int | None) -> int | None: return x ``` ### Missing implementation ```py from typing import overload @overload def foo() -> None: ... # error @overload def foo(x: int) -> int: ... ``` ## References - [Python documentation: `@overload`](https://docs.python.org/3/library/typing.html#typing.overload) # invalid-parameter-default Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for default values that can't be assigned to the parameter's annotated type. ## Why is this bad? This breaks the rules of the type system and weakens a type checker's ability to accurately reason about your code. ## Examples ```python def f(a: int = ""): ... # error ``` # invalid-paramspec Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for the creation of invalid `ParamSpec`s ## Why is this bad? There are several requirements that you must follow when creating a `ParamSpec`. ## Examples ```python from typing import ParamSpec P1 = ParamSpec("P1") # okay # ParamSpec requires a name P2 = ParamSpec() # error ``` ## References - [Typing spec: ParamSpec](https://typing.python.org/en/latest/spec/generics.html#paramspec) # invalid-property-type-override Default level: error | Stable (since 0.0.81) ## What it does Detects overrides that change the readable type of an inherited property incompatibly, restrict the values accepted by its setter, or remove a required write operation. ## Why is this bad? Code using the superclass interface must continue to work on subclass instances. A getter can return a more specific type, but a setter must accept every value accepted by the superclass. A writable attribute cannot be replaced by a read-only property. ## Example ```python class Base: @property def value(self) -> int: return 0 class Child(Base): @property def value(self) -> str: # error: [invalid-property-type-override] return "" ``` An override returning `bool` would be valid because `bool` is a subtype of `int`. # invalid-protocol Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for protocol classes that are invalid at runtime or do not satisfy the typing specification. ## Why is this bad? An invalidly defined protocol class may lead to the type checker inferring unexpected things or accepting unsafe operations. Some invalid protocol definitions also raise `TypeError` at runtime. ## Examples A `Protocol` class cannot inherit from a non-`Protocol` class; this raises a `TypeError` at runtime: ```pycon >>> from typing import Protocol >>> class Foo(int, Protocol): ... Traceback (most recent call last): File "", line 1, in class Foo(int, Protocol): ... TypeError: Protocols can only inherit from other protocols, got ``` A generic protocol's declared type-variable variance must match how that variable is used by its protocol members. For example, a type variable that appears only in a method's return type must be covariant: ```py from typing import Protocol, TypeVar T = TypeVar("T") class Source(Protocol[T]): # error: [invalid-protocol] def read(self) -> T: ... ``` Although Python constructs this protocol successfully at runtime, it is invalid for static typing. Declare the type variable with `TypeVar("T", covariant=True)` instead. # invalid-raise Default level: error | Stable (since 0.0.1-alpha.1) Checks for `raise` statements that raise non-exceptions or use invalid causes for their raised exceptions. ## Why is this bad? Only subclasses or instances of `BaseException` can be raised. For an exception's cause, the same rules apply, except that `None` is also permitted. Violating these rules results in a `TypeError` at runtime. ## Examples ```python def something(): raise NameError def cause() -> None: pass def f(): try: something() except NameError: # error: "Cannot raise object of type `Literal["oops!"]`" # error: "Cannot use object of type `def cause() -> None` as an exception cause" raise "oops!" from cause def g(): # error: "Cannot raise `NotImplemented`" # error: "Cannot use object of type `Literal[42]` as an exception cause" raise NotImplemented from 42 ``` Use instead: ```python def something(): raise NameError def f(): try: something() except NameError as e: raise RuntimeError("oops!") from e def g(): raise NotImplementedError from None ``` ## References - [Python documentation: The `raise` statement](https://docs.python.org/3/reference/simple_stmts.html#raise) - [Python documentation: Built-in Exceptions](https://docs.python.org/3/library/exceptions.html#built-in-exceptions) # invalid-return-type Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Detects returned values that can't be assigned to the function's annotated return type. Note that the special case of a function with a non-`None` return type and an empty body is handled by the separate `empty-body` error code. ## Why is this bad? Returning an object of a type incompatible with the annotated return type is unsound, and will lead to ty inferring incorrect types elsewhere. ## Examples ```python def func() -> int: return "a" # error: [invalid-return-type] ``` # invalid-super-argument Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Detects `super()` calls where: - the first argument is not a valid class literal, or - the second argument is not an instance or subclass of the first argument. ## Why is this bad? `super(type, obj)` expects: - the first argument to be a class, - and the second argument to satisfy one of the following: - `isinstance(obj, type)` is `True` - `issubclass(obj, type)` is `True` Violating this relationship will raise a `TypeError` at runtime. ## Examples ```python class A: ... class B(A): ... super(A, B()) # it's okay! `A` satisfies `isinstance(B(), A)` # `A()` is not a class super(A(), B()) # error # `A()` does not satisfy `isinstance(A(), B)` super(B, A()) # error # `A` does not satisfy `issubclass(A, B)` super(B, A) # error ``` ## References - [Python documentation: super()](https://docs.python.org/3/library/functions.html#super) # invalid-syntax-in-forward-annotation Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for string-literal annotations where the string cannot be parsed as a Python expression. ## Why is this bad? Type annotations are expected to be Python expressions that describe the expected type of a variable, parameter, attribute or `return` statement. Type annotations are permitted to be string-literal expressions, in order to enable forward references to names not yet defined. However, it must be possible to parse the contents of that string literal as a normal Python expression. ## Example ```python def foo() -> "instance of C": # error return 42 class C: ... ``` Use instead: ```python def foo() -> "C": return C() class C: ... ``` ## References - [Typing spec: The meaning of annotations](https://typing.python.org/en/latest/spec/annotations.html#the-meaning-of-annotations) - [Typing spec: String annotations](https://typing.python.org/en/latest/spec/annotations.html#string-annotations) # invalid-total-ordering Default level: error | Stable (since 0.0.10) ## What it does Checks for classes decorated with `@functools.total_ordering` that don't define any ordering method (`__lt__`, `__le__`, `__gt__`, or `__ge__`). ## Why is this bad? The `@total_ordering` decorator requires the class to define at least one ordering method. If none is defined, Python raises a `ValueError` at runtime. ## Example ```python from functools import total_ordering # no ordering method defined @total_ordering # error class MyClass: def __eq__(self, other: object) -> bool: return True ``` Use instead: ```python from functools import total_ordering @total_ordering class MyClass: def __eq__(self, other: object) -> bool: return True def __lt__(self, other: "MyClass") -> bool: return True ``` # invalid-type-alias-type Default level: error | Stable (since 0.0.1-alpha.6) ## What it does Checks for the creation of invalid `TypeAliasType`s ## Why is this bad? There are several requirements that you must follow when creating a `TypeAliasType`. ## Examples ```toml [environment] python-version = "3.12" ``` ```python from typing import TypeAliasType, TypeVar def get_name() -> str: return "NewAlias" IntOrStr = TypeAliasType("IntOrStr", int | str) # okay # TypeAliasType name must be a string literal NewAlias = TypeAliasType(get_name(), int) # error T = TypeVar("T") GenericAlias = TypeAliasType("GenericAlias", list[T], type_params=(T,)) # okay # TypeAliasType type parameters must be type variables InvalidAlias = TypeAliasType("InvalidAlias", list[T], type_params=(list[T],)) # error ``` # invalid-type-arguments Default level: error | Stable (since 0.0.1-alpha.29) ## What it does Checks for invalid type arguments in explicit type specialization. ## Why is this bad? Providing the wrong number of type arguments or type arguments that don't satisfy the type variable's bounds or constraints will lead to incorrect type inference and may indicate a misunderstanding of the generic type's interface. ## Examples Using legacy type variables: ```toml [environment] python-version = "3.12" ``` ```python from typing import Generic, TypeVar T1 = TypeVar("T1", int, str) T2 = TypeVar("T2", bound=int) class Foo1(Generic[T1]): ... class Foo2(Generic[T2]): ... # bytes does not satisfy T1's constraints Foo1[bytes] # error # str does not satisfy T2's bound Foo2[str] # error ``` Using PEP 695 type variables: ```python class Foo[T]: ... class Bar[T, U]: ... # too many arguments Foo[int, str] # error # too few arguments Bar[int] # error ``` # invalid-type-checking-constant Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for a value other than `False` assigned to the `TYPE_CHECKING` variable, or an annotation not assignable from `bool`. ## Why is this bad? The name `TYPE_CHECKING` is reserved for a flag that can be used to provide conditional code seen only by the type checker, and not at runtime. Normally this flag is imported from `typing` or `typing_extensions`, but it can also be defined locally. If defined locally, it must be assigned the value `False` at runtime; the type checker will consider its value to be `True`. If annotated, it must be annotated as a type that can accept `bool` values. ## Examples ```python TYPE_CHECKING: str # error TYPE_CHECKING = "" # error ``` # invalid-type-form Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for expressions that are used as [type expressions] but cannot validly be interpreted as such. ## Why is this bad? Such expressions cannot be understood by ty. In some cases, they might raise errors at runtime. ## Examples ```python from typing import Annotated # Int literals are not allowed in this context in type expressions a: list[1] # error # `Annotated` expects at least two arguments b: Annotated[int] # error ``` [type expressions]: https://typing.python.org/en/latest/spec/annotations.html#type-and-annotation-expressions # invalid-type-guard-definition Default level: error | Stable (since 0.0.1-alpha.11) ## What it does Checks for type guard functions without a first non-self-like non-keyword-only non-variadic parameter. ## Why is this bad? Type narrowing functions must accept at least one positional argument (non-static methods must accept another in addition to `self`/`cls`). Extra parameters/arguments are allowed but do not affect narrowing. ## Examples ```toml [environment] python-version = "3.13" ``` ```python from typing import TypeIs # no parameter def f() -> TypeIs[int]: # error return True # no positional arguments allowed def f(*, v: object) -> TypeIs[int]: # error return True # expected variadic arguments def f(*args: object) -> TypeIs[int]: # error return True class C: # only positional argument is `self` def f(self) -> TypeIs[int]: # error return True ``` # invalid-type-variable-bound Default level: error | Stable (since 0.0.15) ## What it does Checks for [type variables][type variable] whose bounds reference type variables. ## Why is this bad? The bound of a type variable must be a concrete type. ## Examples ```toml [environment] python-version = "3.12" ``` ```python from typing import TypeVar # error: [invalid-type-variable-bound] RecursiveT = TypeVar("RecursiveT", bound=list["RecursiveT"]) U = TypeVar("U") # error: [invalid-type-variable-bound] BoundT = TypeVar("BoundT", bound=U) def f[T: list[T]](): ... # error: [invalid-type-variable-bound] def g[U, T: U](): ... # error: [invalid-type-variable-bound] ``` [type variable]: https://docs.python.org/3/library/typing.html#typing.TypeVar # invalid-type-variable-constraints Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for constrained [type variables] with only one constraint, or that those constraints reference type variables. ## Why is this bad? A constrained type variable must have at least two constraints. ## Examples ```toml [environment] python-version = "3.12" ``` ```python from typing import TypeVar I = TypeVar("I", bound=int) # constraint references `I` S = TypeVar("S", list[I], int) # error # a constrained type variable needs at least two constraints def f[T: (int,)](): ... # error ``` Use instead: ```python from typing import TypeVar U = TypeVar("U", str, int) # valid constrained TypeVar # or T = TypeVar("T", bound=str) # valid bound TypeVar V = TypeVar("V", list[int], int) # valid constrained Type ``` [type variables]: https://docs.python.org/3/library/typing.html#typing.TypeVar # invalid-type-variable-default Default level: error | Stable (since 0.0.16) ## What it does Checks for [type variables] whose default type is not compatible with the type variable's bound or constraints. ## Why is this bad? If a type variable has a bound, the default must be assignable to that bound (see: [bound rules]). If a type variable has constraints, the default must be one of the constraints (see: [constraint rules]). ## Examples ```toml [environment] python-version = "3.13" ``` ```python from typing import TypeVar T = TypeVar("T", bound=str, default=int) # error: [invalid-type-variable-default] U = TypeVar("U", int, str, default=bytes) # error: [invalid-type-variable-default] ``` [bound rules]: https://typing.python.org/en/latest/spec/generics.html#bound-rules [constraint rules]: https://typing.python.org/en/latest/spec/generics.html#constraint-rules [type variables]: https://docs.python.org/3/library/typing.html#typing.TypeVar # invalid-typed-dict-field Default level: error | Stable (since 0.0.28) ## What it does Detects invalid `TypedDict` field declarations. ## Why is this bad? `TypedDict` subclasses cannot redefine inherited fields incompatibly. Doing so breaks the subtype guarantees that `TypedDict` inheritance is meant to preserve. ## Example ```python from typing import TypedDict class Base(TypedDict): x: int class Child(Base): x: str # error: [invalid-typed-dict-field] ``` # invalid-typed-dict-header Default level: error | Stable (since 0.0.14) ## What it does Detects errors in `TypedDict` class headers, such as unexpected arguments or invalid base classes. ## Why is this bad? The typing spec states that `TypedDict`s are not permitted to have custom metaclasses. Using `**` unpacking in a `TypedDict` header is also prohibited by ty, as it means that ty cannot statically determine whether keys in the `TypedDict` are intended to be required or optional. ## Example ```python from typing import TypedDict class Meta(type): ... class Foo(TypedDict, metaclass=Meta): # error: [invalid-typed-dict-header] ... def f(options: dict[str, object]): class Bar(TypedDict, **options): # error: [invalid-typed-dict-header] ... ``` # invalid-typed-dict-statement Default level: error | Stable (since 0.0.9) ## What it does Detects statements other than annotated declarations in `TypedDict` class bodies. ## Why is this bad? `TypedDict` class bodies aren't allowed to contain any other types of statements. For example, method definitions and field values aren't allowed. None of these will be available on "instances of the `TypedDict`" at runtime (as `dict` is the runtime class of all "`TypedDict` instances"). ## Example ```python from typing import TypedDict class Foo(TypedDict): def bar(self): # error: [invalid-typed-dict-statement] pass ``` # invalid-yield Default level: error | Stable (since 0.0.25) ## What it does Detects `yield` and `yield from` expressions where the "yield" or "send" type is incompatible with the generator function's annotated return type. ## Why is this bad? Yielding a value of a type that doesn't match the generator's declared yield type, or using `yield from` with a sub-iterator whose yield or send type is incompatible, is a type error that may cause downstream consumers of the generator to receive values of an unexpected type. ## Examples ```python from typing import Iterator def gen() -> Iterator[int]: yield "not an int" # error: [invalid-yield] ``` # isinstance-against-protocol Default level: error | Stable (since 0.0.14) ## What it does Reports invalid runtime checks against `Protocol` classes. This includes explicit calls `isinstance()`/`issubclass()` against non-runtime-checkable protocols, `issubclass()` calls against protocols that have non-method members, and implicit `isinstance()` checks against non-runtime-checkable protocols via pattern matching. ## Why is this bad? These calls (implicit or explicit) raise `TypeError` at runtime. ## Examples ```python from typing_extensions import Protocol, runtime_checkable class HasX(Protocol): x: int @runtime_checkable class HasY(Protocol): y: int def f(arg: object, arg2: type): # not runtime-checkable isinstance(arg, HasX) # error: [isinstance-against-protocol] # not runtime-checkable issubclass(arg2, HasX) # error: [isinstance-against-protocol] def g(arg: object): match arg: # not runtime-checkable case HasX(): # error: [isinstance-against-protocol] pass def h(arg2: type): isinstance(arg2, HasY) # fine (runtime-checkable) # `HasY` is runtime-checkable, but has non-method members, # so it still can't be used in `issubclass` checks) issubclass(arg2, HasY) # error: [isinstance-against-protocol] ``` ## References - [Typing documentation: `@runtime_checkable`](https://docs.python.org/3/library/typing.html#typing.runtime_checkable) # isinstance-against-typed-dict Default level: error | Stable (since 0.0.15) ## What it does Reports runtime checks against `TypedDict` classes. This includes explicit calls to `isinstance()`/`issubclass()` and implicit checks performed by `match` class patterns. ## Why is this bad? Using a `TypedDict` class in these contexts raises `TypeError` at runtime. ## Examples ```python from typing_extensions import TypedDict class Movie(TypedDict): name: str director: str def f(arg: object, arg2: type): isinstance(arg, Movie) # error: [isinstance-against-typed-dict] issubclass(arg2, Movie) # error: [isinstance-against-typed-dict] def g(arg: object): match arg: case Movie(): # error: [isinstance-against-typed-dict] pass ``` ## References - [Typing specification: `TypedDict`](https://typing.python.org/en/latest/spec/typeddict.html) # mismatched-sentinel-name Default level: ignore | Stable (since 0.0.87) ## What it does Checks for `builtins.sentinel` and `typing_extensions.Sentinel` definitions whose name argument does not match the variable they are assigned to. In class scope, the name can be unqualified or include the full enclosing class path. ## Why is this bad? A mismatched name can be a typo and can make a sentinel's runtime representation confusing. ## Default level This rule is disabled by default because sentinel names are not required to match their assigned variables, and sometimes the preferred `__repr__` for a sentinel may include non-identifier characters. Enable this rule to enforce consistent sentinel naming. This rule is similar to `mismatched-type-name`, but is a distinct rule because the default severity differs. ## Examples ```python from typing_extensions import Sentinel MISSING = Sentinel("OTHER") # error: [mismatched-sentinel-name] ``` Use a matching name instead: ```python from typing_extensions import Sentinel MISSING = Sentinel("MISSING") class Container: UNSET = Sentinel("Container.UNSET") ``` # mismatched-type-name Default level: warn | Stable (since 0.0.30) ## What it does Checks for functional typing definitions whose declared name does not match the variable they are assigned to. ## Why is this bad? Constructors like `TypeVar`, `ParamSpec`, `NewType`, `NamedTuple`, `TypedDict`, and `TypeAliasType` all take a name argument that is normally expected to match the assigned variable. A mismatch is usually a typo and makes later diagnostics harder to understand. `mismatched-sentinel-name` is a similar but distinct rule, disabled by default. ## Default level This rule is a warning by default because ty can usually recover and continue understanding the resulting type. ## Examples ```python from typing import NewType, ParamSpec, TypeVar from typing_extensions import TypedDict T = TypeVar("U") # error: [mismatched-type-name] P = ParamSpec("Q") # error: [mismatched-type-name] UserId = NewType("Id", int) # error: [mismatched-type-name] Movie = TypedDict("Film", {"title": str}) # error: [mismatched-type-name] ``` # missing-argument Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for missing required arguments in a call. ## Why is this bad? Failing to provide a required argument will raise a `TypeError` at runtime. ## Examples ```python def func(x: int): ... # TypeError: func() missing 1 required positional argument: 'x' func() # error ``` # missing-direct-dependency Default level: ignore | Preview (since 0.0.76) ## What it does Checks for imports from installable packages that the current project or PEP 723 script does not declare as direct dependencies. The name used in dependency declarations can differ from the import name: for example, the `pillow` package is imported as `PIL`. ## Why is this bad? A dependency can be installed because another package requires it. Importing that dependency without declaring it makes your code rely on another package's dependency list. If that package removes the dependency, your imports can fail. Declare the packages that provide your imports in `project.dependencies` or `project.optional-dependencies` in `pyproject.toml`. Non-package files, such as tests and development scripts, can also use dependencies declared in dependency groups. See uv's [guide to managing dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/) for how to add these declarations. ## Rule status This rule is disabled by default and requires uv integration. For projects, enable uv workspace integration (`TY_UV=1`) and use an existing, synchronized environment. Running [`uv check`](https://docs.astral.sh/uv/reference/cli/#uv-check) synchronizes the environment automatically before invoking ty, unless `--no-sync` is passed. For these checks, ty reads the dependency graph and module ownership returned by `uv workspace metadata` without changing installed packages. uv may update the lockfile to match the current dependency declarations. uv 0.12.3 or later is required. For PEP 723 scripts, enable uv script integration with `TY_UV=scripts` or `TY_UV=1`. ty synchronizes each script's environment and checks imports against its inline `dependencies` list. Declarations and environments from the enclosing workspace or other scripts do not apply. ## Known limitations Imports guarded by `TYPE_CHECKING` are not reported because they are not executed at runtime. They can use development-only dependencies, such as type stub packages, without requiring those packages as runtime dependencies. Standard-library imports and imports whose owning package cannot be identified unambiguously are also not reported. Imports of [namespace packages](https://docs.python.org/3/reference/import.html#namespace-packages) themselves, such as `import ns`, are not reported: the namespace can contain modules from several installable packages. Imports of their submodules, such as `import ns.child`, are checked when the owning package is known. An `__init__.pyi` stub does not change this distinction. Native packages that ty can resolve only as namespace packages at runtime are also skipped. For other native modules, ty can use stubs to resolve the import and uv's ownership map to identify which package to declare. Some editable installations add the whole project directory to Python's import path, making both package code and files such as `tests/test_app.py` importable. If uv does not identify which modules belong to the installable package, ty allows dependency-group imports throughout that directory, including in package code, to avoid incorrectly flagging imports in tests and scripts. ## Examples With `requests` as a direct dependency, `urllib3` may also be installed because `requests` depends on it: ```python {data-mdtest="ignore"} import requests import urllib3 # error: [missing-direct-dependency] ``` Add `urllib3` to `project.dependencies` if your code imports it directly. # missing-override-decorator Default level: ignore | Stable (since 0.0.41) ## What it does Checks for methods that override a method or attribute in a superclass but are not decorated with `@override`. This rule is disabled by default. Enable it to opt in to strict `@override` enforcement for a project. ## Exemptions Overriding `__init__`, `__new__`, `__init_subclass__`, or `__post_init__` does not require `@override`, even if the method is explicitly declared by a superclass. ## Why is this bad? Without an `@override` annotation, refactors can silently change whether a method is an override. Requiring `@override` on every override lets ty report when an intended override stops overriding anything, and when a method unexpectedly starts overriding a superclass member. ## Example ```toml [environment] python-version = "3.12" ``` ```python from typing import override class Parent: def method(self) -> int: return 1 class Child(Parent): # when the rule is enabled def method(self) -> int: # error return 2 class ExplicitChild(Parent): @override def method(self) -> int: # fine return 2 ``` # missing-slot Default level: error | Stable (since 0.0.75) ## What it does Checks for assignments to declared attributes that have no matching `__slots__` entry on the class or its bases, and no instance dictionary to store their values. ## Why is this bad? Most Python objects store their attributes in an "instance dictionary". Assigning to a new attribute adds an entry to this dictionary; deleting that attribute removes it again. Accordingly, most Python objects allow for **arbitrary attributes to be set and read**. The advantage of this is that it allows for many dynamic features; the disadvantage is that it can be costly in terms of memory, and can easily allow for typos to slip in accidentally, e.g.: ```py class Foo: def __init__(self, x): self.x = x def update_x(self, x): self.xx = x # oops, this was meant to be the same attribute set in `__init__`, # but ended up being an entirely separate one! ``` Defining `__slots__` lets a class reserve space for a fixed set of instance attributes instead. Unless an instance dictionary is inherited from a base class or requested by including `"__dict__"` in `__slots__`, instances of the class have no dictionary in which to store additional attributes. Attempting to assign to an attribute not declared in `__slots__` will often raise `AttributeError` at runtime if the instance has no instance dictionary. ## Examples ### Class definitions ```python class Item: __slots__ = () value: int Item().value = 1 # error: [missing-slot] ``` If you control the class, include the attribute in `__slots__` to make the assignment valid: ```python class Item: __slots__ = ("value",) value: int Item().value = 1 ``` ### Stub files Stub files can use properties to indicate that instances have attributes that are readable and writable but do not appear in `__slots__`, for example: ```pyi class Item: __slots__ = () @property def value(self) -> int: ... @value.setter def value(self, value: int) -> None: ... ``` ## References - [Python data model: `__slots__`](https://docs.python.org/3/reference/datamodel.html#slots) # missing-type-argument Default level: ignore | Stable (since 0.0.45) ## What it does Checks for generic types used without type parameters in type expressions. ## Why is this bad? Using a generic type without specifying its type parameters results in the type parameters being implicitly filled with `Unknown`, reducing the precision of type checking. Explicit type parameters make the intended types clear and enable the type checker to catch more errors. ## Examples ```python import re def handle(m: re.Match) -> str: # error: [missing-type-argument] return m.string # Use explicit type parameters instead: def handle(m: re.Match[str]) -> str: return m.string ``` # missing-typed-dict-key Default level: error | Stable (since 0.0.1-alpha.20) ## What it does Detects missing required keys in `TypedDict` constructor calls. ## Why is this bad? `TypedDict` requires all non-optional keys to be provided during construction. Missing items can lead to a `KeyError` at runtime. ## Example ```python from typing import TypedDict class Person(TypedDict): name: str age: int # missing required key 'age' alice: Person = {"name": "Alice"} # error alice["age"] # KeyError ``` # no-matching-overload Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for calls to an overloaded function that do not match any of the overloads. ## Why is this bad? Failing to provide the correct arguments to one of the overloads will raise a `TypeError` at runtime. ## Examples ```python from typing import overload @overload def func(x: int): ... @overload def func(x: bool): ... def func(x: int | bool): ... func("string") # error: [no-matching-overload] ``` # non-callable-init-subclass Default level: error | Stable (since 0.0.30) ## What it does Checks for class definitions that will fail due to non-callable `__init_subclass__` methods. ## Why is this bad? If a class defines a non-callable `__init_subclass__` method/attribute, any attempt to subclass that class will raise a `TypeError` at runtime. ## Examples ```python class Super: __init_subclass__ = None class Sub(Super): ... # error: [non-callable-init-subclass] ``` ## References - [Python data model: Customizing class creation](https://docs.python.org/3/reference/datamodel.html#customizing-class-creation) # not-iterable Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for objects that are not iterable but are used in a context that requires them to be. ## Why is this bad? Iterating over an object that is not iterable will raise a `TypeError` at runtime. ## Examples ```python # TypeError: 'int' object is not iterable for i in 34: # error pass ``` ## Common issues ### Async generator stubs Calling an `async def` function whose body contains `yield` produces an async iterator, which can be consumed with `async for`. Without `yield`, calling the function produces a coroutine, and its return annotation describes the result of awaiting that coroutine. This distinction matters in stub files, where replacing the implementation with `...` removes the `yield`. For example, this stub describes a coroutine function, even though its return annotation is `AsyncIterator[int]`: `stubs.pyi`: ```pyi from collections.abc import AsyncIterator async def values() -> AsyncIterator[int]: ... ``` Iterating over the coroutine is an error. An `async for` loop awaits each item; it does not automatically await a coroutine to obtain the iterator: `main.py`: ```python from stubs import values async def consume() -> None: # error: "Object of type `CoroutineType[Any, Any, AsyncIterator[int]]` is not async-iterable" async for value in values(): print(value) ``` To declare a function that directly produces an async iterator, use `def` rather than `async def` in the stub: `with_def.pyi`: ```pyi from collections.abc import AsyncIterator def values() -> AsyncIterator[int]: ... ``` Alternatively, keep `async def` and include a `yield` expression in the stub body: `with_yield.pyi`: ```pyi from collections.abc import AsyncIterator async def values() -> AsyncIterator[int]: yield 1 ``` If the function intentionally returns a coroutine that produces an async iterator, await it before iterating: `async for value in await values(): ...`. # not-subscriptable Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for subscripting objects that do not support subscripting. ## Why is this bad? Subscripting an object that does not support it will raise a `TypeError` at runtime. ## Examples ```python # TypeError: 'int' object is not subscriptable 4[1] # error ``` # override-of-final-method Default level: error | Stable (since 0.0.1-alpha.29) ## What it does Checks for methods on subclasses that override superclass methods decorated with `@final`. ## Why is this bad? Decorating a method with `@final` declares to the type checker that it should not be overridden on any subclass. ## Example ```python from typing import final class A: @final def foo(self): ... class B(A): def foo(self): ... # error ``` # override-of-final-variable Default level: error | Stable (since 0.0.16) ## What it does Checks for class variables on subclasses that override a superclass variable that has been declared as `Final`. ## Why is this bad? Declaring a variable as `Final` indicates to the type checker that it should not be overridden on any subclass. ## Example ```python from typing import Final class A: X: Final[int] = 1 class B(A): X = 2 # error ``` # parameter-already-assigned Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for calls which provide more than one argument for a single parameter. ## Why is this bad? Providing multiple values for a single parameter will raise a `TypeError` at runtime. ## Examples ```python def f(x: int) -> int: return x f(1, x=2) # error ``` # positional-only-parameter-as-kwarg Default level: error | Stable (since 0.0.1-alpha.22) ## What it does Checks for keyword arguments in calls that match positional-only parameters of the callable. ## Why is this bad? Providing a positional-only parameter as a keyword argument will raise `TypeError` at runtime. ## Example ```python def f(x: int, /) -> int: return x f(x=1) # error ``` # possibly-missing-attribute Default level: ignore | Stable (since 0.0.1-alpha.22) ## What it does Checks for possibly missing attributes. ## Why is this bad? Attempting to access a missing attribute will raise an `AttributeError` at runtime. ## Rule status This rule is currently disabled by default because of the number of false positives it can produce. ## Examples ```python class A: if __name__ == "__main__": c = 0 # AttributeError: type object 'A' has no attribute 'c' A.c # error ``` # possibly-missing-implicit-call Default level: warn | Stable (since 0.0.1-alpha.22) ## What it does Checks for implicit calls to possibly missing methods. ## Why is this bad? Expressions such as `x[y]` and `x * y` call methods under the hood (`__getitem__` and `__mul__` respectively). Calling a missing method will raise an `AttributeError` at runtime. ## Examples ```python import datetime class A: if datetime.date.today().weekday() != 6: def __getitem__(self, v): ... # TypeError: 'A' object is not subscriptable A()[0] # error ``` # possibly-missing-import Default level: ignore | Stable (since 0.0.1-alpha.22) ## What it does Checks for imports of symbols that may be missing. ## Why is this bad? Importing a missing module or name will raise a `ModuleNotFoundError` or `ImportError` at runtime. ## Rule status This rule is currently disabled by default because of the number of false positives it can produce. ## Examples `module.py`: ```python import datetime if datetime.date.today().weekday() != 6: a = 1 ``` `main.py`: ```python # ImportError: cannot import name 'a' from 'module' from module import a # error ``` # possibly-missing-submodule Default level: warn | Stable (since 0.0.23) ## What it does Checks for accesses of submodules that might not've been imported. ## Why is this bad? When module `a` has a submodule `b`, `import a` isn't generally enough to let you access `a.b.` You either need to explicitly `import a.b`, or else you need the `__init__.py` file of `a` to include `from . import b`. Without one of those, `a.b` is an `AttributeError`. ## Examples ```python import html # AttributeError: module 'html' has no attribute 'parser' html.parser # error ``` # possibly-unresolved-reference Default level: ignore | Stable (since 0.0.1-alpha.1) ## What it does Checks for references to names that are possibly not defined. ## Why is this bad? Using an undefined variable will raise a `NameError` at runtime. ## Rule status This rule is currently disabled by default because of the number of false positives it can produce. ## Example ```python for i in range(int(input())): x = i # NameError: name 'x' is not defined print(x) # error ``` # pydantic-discarded-extra-argument Default level: warn | Stable (since 0.0.60) ## What it does Checks for extra keyword arguments that Pydantic silently discards when a model uses `extra="ignore"`, either implicitly or explicitly. ## Why is this bad? A discarded argument has no effect on the constructed model, but it may indicate a misspelled field name or an incorrect assumption about the model's schema. ## Example ```python {data-mdtest="ignore"} from pydantic import BaseModel class User(BaseModel): name: str admin: bool = False user = User(name="Alice", admni=True) # error: [pydantic-discarded-extra-argument] ``` If the field name has been misspelled, fix the typo. Otherwise, consider removing the extra argument, or explicitly configure the model with `extra="allow"`. # raw-string-type-annotation Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for raw-strings in type annotation positions. ## Why is this bad? Static analysis tools like ty can't analyze type annotations that use raw-string notation. ## Examples ```python def test() -> r"int": # error return 1 ``` Use instead: ```python def test() -> "int": return 1 ``` # redundant-cast Default level: warn | Stable (since 0.0.1-alpha.1) ## What it does Detects redundant `cast` calls where the value already has the target type. ## Why is this bad? These casts have no effect and can be removed. ## Example ```python from typing import cast def f() -> int: return 10 # Redundant cast(int, f()) # error ``` # redundant-condition Default level: warn | Stable (since 0.0.79) ## What it does Detects boolean conditions where the condition can be statically inferred to be always true or always false due to the inferred type of the condition. This rule is enabled by default, and is deliberately not comprehensive. In order to avoid false positives, it excludes conditions that meet any of these criteria: - The boolean test is inferred as evaluating to `True` itself, `False` itself, or an exact integer such as `1` or `0`. - The boolean test can be inferred as always evaluating to `True` and `False`, but this inference is due to boolean-test short-circuiting in `if` conditions, `while` conditions or `assert` tests rather than the inferred type of the boolean test. - The condition uses a walrus operator (`:=`). The assignment's side effect may be intentional, even when its result has fixed truthiness. ## Why is this bad? A boolean condition that is always true or always false usually indicates a mistake in your code, and can often lead to incorrect behavior. If an `if` condition is inferred as always false, moreover, ty will infer all code within that `if` branch as being unreachable, and will not report any diagnostics on code in that region. ## Examples A common error that triggers this rule is to forget to call a function, for example: ```py import random def should_do_action() -> bool: return random.choice([True, False]) # oops! You forgot the parentheses here... this should have been `if should_do_action()`. # Because it's not, this will always be `True`: if should_do_action: # error: [redundant-condition] print("Doing stuff...") ``` Another common mistake is to forget to `await` a coroutine: ```py import random async def should_do_async_action(): return random.choice([True, False]) async def main(): # oops! Forgot the await here... this should have been `if await should_do_async_action()`. # Because it's not, this will always be `True`: if should_do_async_action(): # error: [redundant-condition] print("Doing stuff async...") ``` Or to forget that `tuple[X]` means "A tuple with exactly one element" rather than "a tuple with an arbitrary number of elements" (for which you'd use `tuple[X, ...]`): ```py # you almost certainly meant to write `tuple[str, ...]` here rather than `tuple[str]`... def consume_tuples(x: tuple[str]): # ...and that means that this later condition is inferred as always being True by ty: if x: # error: [redundant-condition] print("Got a non-empty tuple") ``` Some Pythonistas fall into the trap of thinking that a generator expression will be falsy if it has zero elements inside it -- but generator expressions are lazy, and so they're always truthy unless you collect them into a tuple: ```py def test_my_data(data: list[int]): # this will always be `True`, because the asserted object is a `types.GeneratorType` instance, # not a `tuple`! `assert any(item for item in data if item > 42)` # is probably what you meant instead. assert (item for item in data if item > 42) # error: [redundant-condition] ``` ## Boolean operators used to compute values The rule checks `and` and `or` operands when the expression is used as a condition: in an `if`, `elif`, `while`, or `assert` test, a conditional expression, a comprehension filter, a match guard, or as the operand of `not`. It does not flag `and` or `or` expressions used to compute values -- even if an operand in an `and` or `or` expression is always truthy, it doesn't necessarily make the expression redundant: ```py def f(): ... def g(): ... def test(coinflip: bool): # could also be written as `func = f if coinflip else g`, # but use of an `and` expression for this is common in older codebases. func = coinflip and f or g # `func` will be the `f` function if `coinflip` is `True`, # and the `g` function otherwise func() ``` This also allows calls that are deliberately always falsy but are used for their side effects: ```py from unittest.mock import patch def ask_to_continue() -> bool: return input("Continue? ") == "yes" def test_ask_to_continue(): prompts = [] with patch( "builtins.input", side_effect=lambda prompt: prompts.append(prompt) or "yes", ): assert ask_to_continue() assert prompts == ["Continue? "] ``` By contrast, `not` always produces a boolean, so we will still emit a diagnostic on the following example -- negating the truthiness of a function object is pointless, since a function object is always truthy: ```py def f(): ... value = not f # error: [redundant-condition] ``` ## Known issues and workarounds This rule can sometimes trigger on code that is not incorrect, but could be written in a clearer way. For example, the rule will flag this code: ```py def find_duplicate_coordinates(coordinates: list[tuple[int, int]]): seen: set[tuple[int, int]] = set() # error: [redundant-condition] "Expression `seen.add(coord)` is always falsy (has type `None`)" duplicates = {coord for coord in coordinates if coord in seen or seen.add(coord)} print(f"Duplicates are {duplicates}") ``` The error here is triggered due to `seen.add(coord)` being used in a boolean expression, despite the fact that `set.add()` always returns `None`. Here this is deliberate: `set.add()` is being used for its side effect. To workaround this issue, the above code could be rewritten like this, which may also be easier for some readers to understand: ```py def find_duplicate_coordinates(coordinates: list[tuple[int, int]]): seen: set[tuple[int, int]] = set() duplicates: set[tuple[int, int]] = set() for coord in coordinates: if coord in seen: duplicates.add(coord) else: seen.add(coord) print(f"Duplicates are {duplicates}") ``` ## See also - `truthiness-test-of-callable` detects suspicious boolean tests where `Callable`-typed variables are tested for their truthiness - `truthiness-test-of-iterable` detects suspicious boolean tests where `Iterable`-typed variables are tested for their truthiness # redundant-condition-strict Default level: ignore | Stable (since 0.0.79) ## What it does Detects boolean conditions where the condition can be statically inferred to be always true or always false. This rule is disabled by default. It exclusively covers cases that its sibling (enabled-by-default) rule `redundant-condition` does not cover. These cases often flag real bugs in user code, but also have a significantly higher rate of unavoidable false positives than other cases. This rule reports redundant conditions that meet any of these criteria: - The boolean test is inferred as evaluating to `True` itself, `False` itself, or an exact integer such as `1` or `0`. - Short-circuit evaluation means the condition can be guaranteed to be always truthy or always falsy despite fixed truthiness not being guaranteed by the inferred type of the expression's value (see "Short-circuiting boolean conditions" below for an example). - The condition uses a walrus operator (`:=`). The assignment's side effect may be intentional, even when its result has fixed truthiness. ## Why is this bad? A boolean condition that is always true or always false usually indicates a mistake in your code, and can often lead to incorrect behavior. If an `if` condition is inferred as always false, moreover, ty will infer all code within that `if` branch as being unreachable, and will not report any diagnostics on code in that region. ## Examples A common error in Python code is to make the mistake of thinking that indexing into a `bytes` object will get you an object of type `bytes`. But `bytes` work differently to `str`s in Python -- although a string is a sequence of strings, a bytestring is a sequence of `int`s, so indexing into a `bytes` object gives you an `int`. This rule can catch that error by alerting you to the fact that checking whether a `bytes` object is unequal to an `int` will always evaluate to `True`: ```py def validate_record(data: bytes) -> None: if data[0] != b"\x1e": # error: [redundant-condition-strict] raise ValueError("Invalid record separator") ``` Another common mistake is to assume that annotating `**kwargs` with `dict[str, str]` describes the dictionary containing the keyword arguments. In fact, a `**kwargs` annotation describes each individual keyword argument, so this annotation says that every value is itself a dictionary. Comparing one of those values with a string will therefore always evaluate to `False`: ```py def trace(**kwargs: dict[str, str]) -> None: if kwargs.get("operation") == "task": # error: [redundant-condition-strict] print("Tracing task") ``` ## Short-circuiting boolean conditions In some situations, ty can know that a condition will always be true, or it can know that a condition will always be false, even when this is not guaranteed by the inferred type of that condition. This is because of the way that Python short-circuits evaluation of conditions in the context of `if` tests, `while` tests and `assert` statements. Consider a class whose comparison method has an `object` return type: ```py from typing_extensions import reveal_type class Comparable: def __lt__(self, other: int) -> object: ... def check(value: Comparable): reveal_type(value < 1 < 0) # revealed: ~AlwaysTruthy if value < 1 < 0: # error: [redundant-condition-strict] "always false" pass ``` Outside the context of an `if` test, the revealed type of the condition here is `~AlwaysTruthy`: in other words, ty knows that this expression is not *always true*, but cannot guarantee that it is definitely *always false*. It could be an object that is sometimes true and sometimes false -- for example, a `list` (which is falsy when it is empty, and truthy otherwise). Nonetheless, when `value < 1 < 0` is used directly as a condition, ty knows that the condition will always be falsy and the `if` branch will never be taken. Python tests the truthiness of the object returned by `Comparable.__lt__` once: if it is falsy, the condition fails immediately. If it is truthy, Python evaluates `1 < 0`, which is false. There is no second truthiness test of the object returned by `__lt__`. If the chained comparison is saved as a variable first, its value can be the object returned by `__lt__`, if that object was falsy when first tested. The `if result` statement then tests that object's truthiness again. A user-defined `__bool__` method can return a different result on that second call, so ty cannot guarantee that the saved value is still falsy, and no diagnostic is emitted: ```py def check_saved(value: Comparable): result = value < 1 < 0 if result: # no diagnostic pass ``` ## Exemptions Like `redundant-condition`, this rule checks subexpressions of an `and` or `or` expression only when the outer expression is used as a condition. This is to avoid emitting false-positive diagnostics on code like the following, where the `and` expression is clearly not redundant despite the fact that both `CONSTANT_1` and `CONSTANT_2` are always truthy: ```py from typing import Final CONSTANT_1: Final = 1 CONSTANT_2: Final = 2 def do_something(coinflip: bool): # could also be written as `constant_to_use = CONSTANT_1 if coinflip else CONSTANT_2`, # but use of an `and` expression for this is common in older codebases. constant_to_use = coinflip and CONSTANT_1 or CONSTANT_2 # do something with `constant_to_use` now... ... ``` Unlike `and` and `or`, however, `not` explicitly converts its operand to a boolean, so the rule checks `not` expressions in every context. Another exemption applied by this rule concerns `assert`-statement tests. A common pattern in Python code is to use defensive `assert`s to enforce behaviour at runtime, even when the asserted condition can be inferred statically to be always true. For example: ```py def add_one(x: int) -> int: assert isinstance(x, int) # no diagnostic return x + 1 ``` This kind of defensive behaviour is often reasonable, since the author of a library cannot guarantee that end users of the library will run a type checker on code calling into the library, meaning that it's entirely possible at runtime for an object passed into the `x`a parameter above to be a `str` (for example) even though the parameter annotation states that only `int`s can ever be passed in. This rule therefore also exempts all assertion tests or subexpressions that evaluate to a subtype of `int` or `bool`: `redundant-condition-strict` can still trigger on `assert` statements in some contexts, however. For example, `redundant-condition-strict` will be emitted on the below example, where the left-hand side of the `and` expression is always true and not a subtype of `bool` or `int`, but where the condition is nonetheless excluded from the enabled-by-default `redundant-condition` rule due to the use of the walrus operator: ```py def func() -> bool: return True def test_func(): assert (result := func) and result != func() # error: [redundant-condition-strict] ``` For similar reasons to the `assert` exemptions, this rule also exempts always-false `if` or `elif` conditions when their bodies end in a defensive check: a `raise`, an assertion that could fail, a call returning `Never`, an `await` to a call returning `Never`, or `return NotImplemented`: ```py import sys def add_two(x: int) -> int: if not isinstance(x, int): # no diagnostic raise TypeError("need an int!!") return x + 2 def add_three(x: int) -> int: if not isinstance(x, int): # no diagnostic assert False, "unreachable" return x + 3 def add_four(x: int) -> int: if not isinstance(x, int): # no diagnostic sys.exit(1) return x + 4 class Foo: def __init__(self, data: int): self.data = data def __add__(self, other: "Foo"): if not isinstance(other, Foo): # no diagnostic return NotImplemented return Foo(self.data + other.data) ``` And an exemption is applied for always-true `if` or `elif` statements that are followed by branches which contain defensive checks: ```py from typing_extensions import assert_never def parse_data(data: int | str): if isinstance(data, int): print("got an int") elif isinstance(data, str): # Always true, but no diagnostic, since # the `else` branch following this branch is always terminal. # (`assert_never` returns `Never`, indicating that it always raises an exception) print("got a str") else: assert_never(data) def parse_data_early_return(data: int | str): if isinstance(data, int): print("got an int") return # Always true, but no diagnostic, since # the suite following this branch is always terminal # (every control-flow path following this `if` statement ends in a `raise` statement) if isinstance(data, str): print("got a str") return raise AssertionError("unexpected data") ``` Any conditions defined in relation to `sys.version_info`, `sys.platform`, `os.name` or `typing.TYPE_CHECKING` are also exempted. The rule recursively follows the definitions of names and attributes across module boundaries to determine if a name or attribute was indirectly defined in relation to one of these highly special-cased symbols: ```toml [environment] python-version = "3.14" python-platform = "linux" ``` ```py import os import sys from typing import TYPE_CHECKING if sys.version_info >= (3, 14): # inferred as always true here, but no diagnostic pass if sys.platform == "win32": # inferred as always false here, but no diagnostic pass LINE_ENDING = "\n" if os.name == "posix" else "\r\n" if LINE_ENDING == "\n": # inferred as always true here, but no diagnostic pass if TYPE_CHECKING: # inferred as always true, but no diagnostic pass ``` Conditions involving these constants, or conditions involving values defined in relation to these constants, can often be inferred as always-true or always-false by ty. Indeed, these conditions usually *will* be always true or always false across a single invocation run of a Python programme. Nonetheless, Python code is often written so that it can work on multiple different Python versions and/or multiple different operating systems, and a condition that is always true on one operating system might very well be always false on another operating system (for example). Flagging these conditions as being always true or always false would only add noise: the aim of the rule is to flag conditions that are *unintentionally* always true or always false. Lastly, some conditions involving literal integers and booleans in the AST are also exempted: there's no reason why you'd use a condition like this unless it was intentional. ```py if True: # inferred as always true (obviously), but no diagnostic pass if 0: pass # inferred as always false, but no diagnostic ``` ## Known issues and workarounds This rule can often trigger on code that is not incorrect, but could be written in a clearer way. For example, the rule will flag this code: ```py from enum import Enum class YesOrNo(Enum): YES = 1 NO = 0 def say_yes_or_no(what_to_say: YesOrNo): if what_to_say == YesOrNo.YES: print("yes") elif what_to_say == YesOrNo.NO: # error: [redundant-condition-strict] print("no") ``` This snippet could be written more clearly as this, which would not trigger the rule owing to the exemptions described in the section above: ```py def say_yes_or_no(what_to_say: YesOrNo): if what_to_say == YesOrNo.YES: print("yes") else: assert what_to_say == YesOrNo.NO print("no") ``` or the snippet could also be rewritten as this, which would also be fine according to the rule's heuristics: ```py from typing_extensions import assert_never def say_yes_or_no(what_to_say: YesOrNo): if what_to_say == YesOrNo.YES: print("yes") elif what_to_say == YesOrNo.NO: print("no") else: assert_never(what_to_say) ``` In a similar vein, this rule can often flag `and` or `or` expressions that have operands which are deliberately always truthy or deliberately always falsy, because the purpose of the operand is to have some side effect occur. For example: ```py import random from typing import Literal def want_to_go_fishing() -> bool: return random.choice([True, False]) def weather_report() -> Literal["rainy", "sunny", "cloudy"]: return random.choice(["rainy", "sunny", "cloudy"]) def have_fishing_supplies() -> bool: return random.choice([True, False]) def main(): if ( want_to_go_fishing() and (weather := weather_report()) # error: [redundant-condition-strict] and have_fishing_supplies() ): print(f"The weather is {weather}, let's go fishing") ``` The middle operand in the above `and` expression is always truthy. This might be deliberate, but even if it is, the function would arguably be clearer if it were written like this instead: ```py def main(): if want_to_go_fishing(): weather = weather_report() if have_fishing_supplies(): print(f"The weather is {weather}, let's go fishing") ``` Lastly, the rule cannot reliably distinguish in all cases comparisons that are intentionally always true/false from those that are unintentionally always true/false. The rule takes care to avoid flagging code that uses `if TYPE_CHECKING`, `if sys.version_info < (X, Y)`, `if sys.platform == ...` and `if os.name == ...`. But it cannot reliably determine that code like this was written the way it was meant to be: ```py DEBUGGING = 0 if DEBUGGING: # error: [redundant-condition-strict] print("Doing debugging stuff...") ``` ## See also - `truthiness-test-of-callable` detects suspicious boolean tests where `Callable`-typed variables are tested for their truthiness - `truthiness-test-of-iterable` detects suspicious boolean tests where `Iterable`-typed variables are tested for their truthiness # redundant-final-classvar Default level: warn | Stable (since 0.0.18) ## What it does Checks for redundant combinations of the `ClassVar` and `Final` type qualifiers. ## Why is this bad? An attribute that is marked `Final` in a class body is implicitly a class variable. Marking it as `ClassVar` is therefore redundant. Note that this diagnostic is not emitted for dataclass fields or protocol members, where `ClassVar[Final[int]]` has a distinct meaning from `Final[int]`. ## Examples ```python from typing import ClassVar, Final class C: # redundant x: ClassVar[Final[int]] = 1 # error # redundant y: Final[ClassVar[int]] = 1 # error ``` # shadowed-type-variable Default level: error | Stable (since 0.0.20) ## What it does Checks for type variables in nested generic classes or functions that shadow type variables from an enclosing scope. ## Why is this bad? Shadowing type variables makes the code confusing and is disallowed by the typing spec. ## Examples ```toml [environment] python-version = "3.12" ``` ```python class Outer[T]: # `T` is already used by `Outer` class Inner[T]: ... # error # `T` is already used by `Outer` def method[T](self, x: T) -> T: # error return x ``` ## References - [Typing spec: Generics](https://typing.python.org/en/latest/spec/generics.html#introduction) # static-assert-error Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Makes sure that the argument of `static_assert` is statically known to be true. ## Why is this bad? A `static_assert` call represents an explicit request from the user for the type checker to emit an error if the argument cannot be verified to evaluate to `True` in a boolean context. ## Examples ```python from ty_extensions import static_assert # evaluates to `False` static_assert(1 + 1 == 3) # error # does not have a statically known truthiness static_assert(int(2.0 * 3.0) == 6) # error ``` # subclass-of-dataclass-with-order Default level: warn | Stable (since 0.0.39) ## What it does Checks for classes that inherit from a dataclass with `order=True`. ## Why is this bad? When a dataclass has `order=True`, comparison methods (`__lt__`, `__le__`, `__gt__`, `__ge__`) are generated that compare instances as tuples of their fields. These methods raise a `TypeError` at runtime when comparing instances of different classes in the inheritance hierarchy, even if one is a subclass of the other. This violates the [Liskov Substitution Principle][liskov-substitution-principle] because child class instances cannot be used in all contexts where parent class instances are expected. ## Example ```python from dataclasses import dataclass @dataclass(order=True) class Parent: value: int class Child(Parent): # error pass # At runtime, this raises TypeError: # Child(1) < Parent(2) ``` Consider using [`functools.total_ordering`][total_ordering] instead, which does not have this limitation. [liskov-substitution-principle]: https://en.wikipedia.org/wiki/Liskov_substitution_principle [total_ordering]: https://docs.python.org/3/library/functools.html#functools.total_ordering # subclass-of-final-class Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for classes that subclass final classes. ## Why is this bad? Decorating a class with `@final` declares to the type checker that it should not be subclassed. ## Example ```python from typing import final @final class A: ... class B(A): ... # error ``` # super-call-in-named-tuple-method Default level: error | Stable (since 0.0.1-alpha.30) ## What it does Checks for calls to `super()` inside methods of `NamedTuple` classes. ## Why is this bad? Using `super()` in a method of a `NamedTuple` class will raise an exception at runtime. ## Examples ```python from typing import NamedTuple class F(NamedTuple): x: int def method(self): # super() is not supported in methods of NamedTuple classes super() # error ``` ## References - [Python documentation: super()](https://docs.python.org/3/library/functions.html#super) # too-many-positional-arguments Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for calls that pass more positional arguments than the callable can accept. ## Why is this bad? Passing too many positional arguments will raise `TypeError` at runtime. ## Example ```python def f(): ... f("foo") # error ``` # truthiness-test-of-callable Default level: warn | Stable (since 0.0.83) ## What it does Detects suspicious truthiness tests of `Callable`-typed values and unions of callable types. ## Why is this bad? `Callable`-typed variables are nearly always functions in practice, and functions are always truthy. If `predicate` is a variable inferred as having a `Callable` type, therefore, a boolean test such as `if predicate:` is usually not what you want; `if predicate()` (or similar) is usually what was intended. ## Examples ```py from collections.abc import Callable def announce_if_ready(is_ready: Callable[[], bool]): if is_ready: # error: [truthiness-test-of-callable] print("Ready") ``` You probably meant to call the value instead: ```py def announce_if_ready_fixed(is_ready: Callable[[], bool]): if is_ready(): # no diagnostic print("Ready") ``` ## See also - `redundant-condition` and `redundant-condition-strict` detect conditions that can be inferred as always being truthy or falsy - `truthiness-test-of-iterable` detects suspicious boolean tests where `Iterable`-typed variables are tested for their truthiness # truthiness-test-of-iterable Default level: warn | Stable (since 0.0.83) ## What it does Detects boolean conditions where variables typed as `Iterable`, `Iterator`, `Generator` or similar are tested for their truthiness. ## Why is this bad? Testing an `Iterable` object for truthiness strongly suggests that the code expects the object to evaluate as falsy in a boolean context if it is empty. However, even empty `Iterable` objects can be truthy if they do not define `__len__` or `__bool__`. The classic example of this is a generator: unevaluated generators in Python are always truthy, even if they do not yield any elements at runtime. ## Examples ```py from collections.abc import Iterable def process(items: Iterable[int]): if items: # error: [truthiness-test-of-iterable] print("Received items") else: print("Didn't receive any items") # prints "Received items", even though the passed-in generator is empty! process(x for x in range(42) if x > 43) ``` If `process` in the above example does not need to accept generators, one solution is to rewrite the annotation to use `Collection` instead of `Iterable`. `Collection` mandates that the object passed in must define `__len__`, making a truthiness test much more likely to be meaningful: ```py from collections.abc import Collection def process(items: Collection[int]): if items: # no diagnostic print("Received items") else: print("Didn't receive any items") # passing in a generator is now rejected: # error: [invalid-argument-type] "Expected `Collection[int]`, found `GeneratorType[int, None, None]`" process(x for x in range(42) if x > 43) ``` If the function must also accept generators, another solution can be to collect the iterable into a tuple or list before testing its length: ```py def process(items: Iterable[int]): collected = tuple(items) if collected: # no diagnostic print("Received items") else: print("Didn't receive any items") # correctly prints "Didn't receive any items" process(x for x in range(42) if x > 43) ``` ## See also - `redundant-condition` and `redundant-condition-strict` detect conditions that can be inferred as always being truthy or falsy - `truthiness-test-of-callable` detects suspicious boolean tests where `Callable`-typed variables are tested for their truthiness # truthiness-test-of-none-union Default level: ignore | Stable (since 0.0.84) ## What it does Detects truthiness checks of unions with `None` whose non-`None` part can also be falsy, like an `if value: ...` check on a value of type `int | None`. This rule is disabled by default. It can catch mistakes where a valid value is confused with missing data, but may also flag code that deliberately treats `None` and other falsy values alike. ## Why is this bad? `None` is a sentinel often used to indicate the absence of a meaningful value. A variable annotated as `int | None` can hold an integer or `None`. Since `None` is falsy, testing an object's truthiness is a common way to check whether a value is present, but this can lead to incorrect behavior. An object of type `int | None` can still be falsy even if it is an integer, since `0` is falsy. Boolean tests on objects of type `str | None`, `bytes | None`, or `list | None` have similar pitfalls: an empty string, bytestring, or list is also falsy in Python. ## Examples Consider a function that returns at most a given number of items, or all items if no limit was provided: ```py def take(items: list[str], limit: int | None = None) -> list[str]: if not limit: # error: [truthiness-test-of-none-union] return items return items[:limit] ``` The intention here is that `take(items, 0)` should return no items. But because both `None` and `0` are falsy, it returns all of them instead. Checking explicitly for `None` fixes the mistake: ```py def take(items: list[str], limit: int | None = None) -> list[str]: if limit is None: return items return items[:limit] ``` ## Known issues and workarounds This rule can trigger on conditions that intentionally treat missing and empty values alike. For example, the following function intentionally treats both `None` and empty lists as equivalent: ```py def default_preset(presets: list[str] | None) -> str: if presets: # error: [truthiness-test-of-none-union] return presets[0] return "auto" ``` Replacing the condition with `presets is not None` would introduce an `IndexError` for an empty list. Checking that `presets` is a list before testing its truthiness preserves the intended behavior without triggering the rule: ```py def default_preset(presets: list[str] | None) -> str: if isinstance(presets, list) and presets: return presets[0] return "auto" ``` ## See also `redundant-condition` and `redundant-condition-strict` detect Boolean conditions that are always true or always false. # type-assertion-failure Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for `assert_type()` and `assert_never()` calls where the actual type is not the same as the asserted type. ## Why is this bad? `assert_type()` allows confirming the inferred type of a certain value. ## Example ```toml [environment] python-version = "3.11" ``` ```python from typing import assert_type def _(x: int): assert_type(x, int) # fine # Actual type does not match asserted type assert_type(x, str) # error ``` # unavailable-implicit-super-arguments Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Detects invalid `super()` calls where implicit arguments like the enclosing class or first method argument are unavailable. ## Why is this bad? When `super()` is used without arguments, Python tries to find two things: the nearest enclosing class and the first argument of the immediately enclosing function (typically self or cls). If either of these is missing, the call will fail at runtime with a `RuntimeError`. ## Examples ```python # no enclosing class or function found super() # error def func(): # no enclosing class or first argument exists super() # error class A: # no enclosing function to provide the first argument f = super() # error def method(self): def nested(): # first argument does not exist in this nested function super() # error # first argument does not exist in this lambda lambda: super() # error # argument is not available in generator expression (super() for _ in range(10)) # error super() # okay! both enclosing class and first argument are available ``` ## References - [Python documentation: super()](https://docs.python.org/3/library/functions.html#super) # unbound-type-variable Default level: error | Stable (since 0.0.20) ## What it does Checks for type variables that are used in a scope where they are not bound to any enclosing generic context. ## Why is this bad? Using a type variable outside of a scope that binds it has no well-defined meaning. ## Examples ```python from typing import TypeVar, Generic T = TypeVar("T") S = TypeVar("S") # unbound type variable in module scope x: T # error class C(Generic[T]): # S is not in this class's generic context x: list[S] = [] # error ``` ## References - [Typing spec: Scoping rules for type variables](https://typing.python.org/en/latest/spec/generics.html#scoping-rules-for-type-variables) # undefined-reveal Default level: warn | Stable (since 0.0.1-alpha.1) ## What it does Checks for calls to `reveal_type` without importing it. ## Why is this bad? Using `reveal_type` without importing it will raise a `NameError` at runtime. ## Examples ```python # NameError: name 'reveal_type' is not defined # error reveal_type(1) # revealed: Literal[1] ``` # unknown-argument Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for keyword arguments in calls that don't match any parameter of the callable. ## Why is this bad? Providing an unknown keyword argument will raise `TypeError` at runtime. ## Example ```python def f(x: int) -> int: return x f(x=1, y=2) # error ``` # unresolved-attribute Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for unresolved attributes. ## Why is this bad? Accessing an unbound attribute will raise an `AttributeError` at runtime. An unresolved attribute is not guaranteed to exist from the type alone, so this could also indicate that the object is not of the type that the user expects. ## Examples ```python class A: ... # AttributeError: 'A' object has no attribute 'foo' A().foo # error ``` # unresolved-global Default level: warn | Stable (since 0.0.1-alpha.15) ## What it does Detects variables declared as `global` in an inner scope that have no explicit bindings or declarations in the global scope. ## Why is this bad? Function bodies with `global` statements can run in any order (or not at all), which makes it hard for static analysis tools to infer the types of globals without explicit definitions or declarations. ## Example ### Assigning without a global-scope declaration ```python def f(): # unresolved global global x # error x = 42 def g(): print(x) # unresolved reference ``` ### Use instead #### Declare the global ```python x: int def f(): global x x = 42 def g(): print(x) ``` #### Initialize the global ```python x: int | None = None def f(): global x x = 42 def g(): print(x) ``` # unresolved-import Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for import statements for which the module cannot be resolved. ## Why is this bad? Importing a module that cannot be resolved will raise a `ModuleNotFoundError` at runtime. These diagnostics can often be caused due to ty's Python environment or search paths being configured incorrectly. See the [import troubleshooting FAQ](https://docs.astral.sh/ty/reference/typing-faq/#why-cant-ty-resolve-my-imports) for more details. ## Examples ```python # ModuleNotFoundError: No module named 'mathh' import mathh # error ``` # unresolved-reference Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for references to names that are not defined. ## Why is this bad? Using an undefined variable will raise a `NameError` at runtime. ## Example ```python # NameError: name 'x' is not defined print(x) # error ``` # unsound-assignment Default level: ignore | Stable (since 0.0.73) ## What it does Detects variable assignments that unsoundly assign a type that is not a [subtype] of a variable's declared type. This rule is a stricter version of `invalid-assignment`. Whereas that rule also flags assignments to attributes and subscripts, however, this rule is only applied to variable assignments. This rule has no effect on stub files. ## Why is this bad? By default, type checkers consider an assignment valid if the inferred type of the assigned value is [assignable] to the target's declared type. However, this makes it easy for incorrect types to percolate through your code unexpectedly due to a single expression being inferred as `Any`. This can easily lead to runtime errors that are not caught by the type checker: ```py from typing import Any def returns_any() -> Any: return "not an integer" # error: "Unsound assignment: `Any` is not a subtype of `int`" my_integer: int = returns_any() # Fails at runtime, even though the type checker infers both operands as being of type `int`! my_integer + 42 ``` This rule treats ["fully static"][fully-static] declared types as "typed boundaries" for your code. With this rule enabled, ty would emit an error on the `my_integer: int = returns_any()` assignment, since the `returns_any()` call is inferred as having type `Any`, and `Any` is not a subtype of `int`. This helps prevent the unsoundness from spreading far from its original source (in this case, the return type of the `returns_any` function). Note that this rule is only applied to assignments where the declared type is [fully static][fully-static]. It will not trigger if `Any` or `Unknown` appear anywhere in the declared type, either implicitly or explicitly: ```py from typing import Any def returns_any() -> Any: return "not an integer" explicitly_dynamic: Any = returns_any() # no error also_dynamic: list[Any] = returns_any() # no error # no `unsound-assignment` error, since `list` is implicitly the same as `list[Unknown]` # (which is what the `missing-type-argument` error is complaining about) # # error: [missing-type-argument] implicitly_dynamic: list = returns_any() ``` This rule works especially well when combined with ty's `missing-type-argument` rule. ## Examples ```py from typing import Any def returns_any() -> Any: return 42 # error: "Unsound assignment: `Any` is not a subtype of `int`" my_integer: int = returns_any() another_integer: int # error: "Unsound assignment: `Any` is not a subtype of `int`" another_integer = returns_any() ``` Narrow the value before assigning it to fix the diagnostics: ```py from typing import Any def returns_any() -> Any: return 42 value = returns_any() assert isinstance(value, int) my_integer: int = value # no error: `Any & int` is a subtype of `int` ``` ## Default level This rule is disabled by default. It is intended for advanced users wanting additional soundness checks from their type checker, not for users who have just started to use type checkers on their Python code. ## See also - `unsound-return-statement` is a similar rule that triggers on unsound `return` statements rather than unsound assignments - `unsound-yield` is a similar rule that triggers on unsound `yield` expressions rather than unsound assignments [assignable]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable [fully-static]: https://typing.python.org/en/latest/spec/glossary.html#term-fully-static-type [subtype]: https://typing.python.org/en/latest/spec/glossary.html#term-subtype # unsound-return-statement Default level: ignore | Stable (since 0.0.70) ## What it does Detects `return` statements that unsoundly return a type that is not a [subtype] of the function's annotated return type. This lint is a stricter version of `invalid-return-type`. ## Why is this bad? By default, type checkers consider a `return` statement valid if the inferred type of the object being returned is [assignable] to the annotated return type of the function it's in. However, this makes it easy for incorrect types to percolate through your code unexpectedly due to a single expression being inferred as `Any`. This can easily lead to runtime errors that are not caught by the type checker: ```py from typing import Any def returns_any() -> Any: return "foo" def returns_int() -> int: # error: "Unsound return statement: `Any` is not a subtype of `int`" return returns_any() # fails at runtime, even though the type checker infers both operands as being of type `int`! returns_int() + 42 ``` This rule allows you to use ["fully static"][fully-static] return types as "typed boundaries" for your code. With this rule enabled, ty would emit an error on the `return returns_any()` statement in `returns_int`, since the `returns_any()` call is inferred as having type `Any`, and `Any` is not a subtype of `int`. This helps prevent the unsoundness from spreading far from its original source (in this case, the return type of the `returns_any` function). Note that this rule is only applied to functions annotated as returning [fully static][fully-static] types. It will not trigger if `Any` or `Unknown` appear anywhere in your return type, either implicitly or explicitly: ```py from typing import Any def returns_any() -> Any: return "foo" # error: [missing-type-argument] def returns_unparameterized_tuple() -> tuple: # no error, since the return type is implicitly `tuple[Unknown, ...]` # (which is what the `missing-type-argument` error is complaining about on the line above!) return returns_any() def returns_list_of_any() -> list[Any]: # no error, since the return type is explicitly `list[Any]` return returns_any() ``` This rule works especially well when combined with ty's `missing-type-argument` and `unsound-assignment` rules, as well as the Ruff rules [`ANN201`][ann201], [`ANN202`][ann202], [`ANN204`][ann204], [`ANN205`][ann205], and [`ANN206`][ann206]. Enabling all these rules at once effectively makes it much less likely that a `return` statement can lead to unsoundness "leaking" out of a function unless that function has been *explicitly* annotated with a dynamic type in some way (`-> Any` or `-> tuple[Any]`, for example). This rule is analogous to mypy's [`no-any-return`][no-any-return] error code, which is enabled by mypy’s [`--strict`][mypy-strict] mode and can also be enabled on its own using mypy’s [`--warn-return-any`][warn-return-any] option. ## Examples ```py from typing import Any def returns_any() -> Any: return 42 def returns_int() -> int: # error: "Unsound return statement: `Any` is not a subtype of `int`" return returns_any() ``` Narrow the type to a subtype of `int` to fix the diagnostic: ```py from typing import Any from typing_extensions import reveal_type def returns_any() -> Any: return 42 def returns_int() -> int: my_int = returns_any() assert isinstance(my_int, int) reveal_type(my_int) # revealed: Any & int return my_int # no error: `Any & int` is a subtype of `int` ``` ## Default level This rule is disabled by default. It is intended for advanced users wanting additional soundness checks from their type checker, not for users who have just started to use type checkers on their Python code. ## See also - `unsound-yield` is a similar rule that triggers on unsound `yield` expressions rather than unsound `return` statements - `unsound-assignment` is a similar rule that triggers on unsound assignments [ann201]: https://docs.astral.sh/ruff/rules/missing-return-type-undocumented-public-function/ [ann202]: https://docs.astral.sh/ruff/rules/missing-return-type-private-function/ [ann204]: https://docs.astral.sh/ruff/rules/missing-return-type-special-method/ [ann205]: https://docs.astral.sh/ruff/rules/missing-return-type-static-method/ [ann206]: https://docs.astral.sh/ruff/rules/missing-return-type-class-method/ [assignable]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable [fully-static]: https://typing.python.org/en/latest/spec/glossary.html#term-fully-static-type [mypy-strict]: https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-strict [no-any-return]: https://mypy.readthedocs.io/en/stable/error_code_list2.html#code-no-any-return [subtype]: https://typing.python.org/en/latest/spec/glossary.html#term-subtype [warn-return-any]: https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-warn-return-any # unsound-yield Default level: ignore | Stable (since 0.0.70) ## What it does Detects `yield` and `yield from` expressions that unsoundly yield a type that is not a [subtype] of the generator function's annotated yield type. This lint is a stricter version of `invalid-yield`. ## Why is this bad? By default, type checkers consider a yielded value valid if its inferred type is [assignable] to the generator's annotated yield type. However, this makes it easy for incorrect types to percolate through your code unexpectedly due to a single expression being inferred as `Any`. This can easily lead to runtime errors that are not caught by the type checker: ```py from typing import Any, Generator def returns_any() -> Any: return "not an integer" def integers() -> Generator[int]: # error: "Unsound `yield`: `Any` is not a subtype of `int`" yield returns_any() # Fails at runtime, even though the type checker infers `integers` as yielding only `int`s! sum(integers()) ``` This rule treats ["fully static"][fully-static] yield types as "typed boundaries" for your code. With this rule enabled, ty would emit an error on the `yield returns_any()` statement in `integers`, since the `returns_any()` call is inferred as having type `Any`, and `Any` is not a subtype of `int`. This helps prevent the unsoundness from spreading far from its original source (in this case, the return type of the `returns_any` function). Note that this rule is only applied to functions annotated as yielding [fully static][fully-static] types. It will not trigger if `Any` or `Unknown` appear anywhere in your function's yield type, either implicitly or explicitly. It will still trigger on functions that have non-fully-static send and/or return types, however: ```py from typing import Any, Generator def returns_any() -> Any: return "not an integer" def dynamic_yield_type() -> Generator[Any]: # no error yield returns_any() def static_yield_type() -> Generator[int, Any, Any]: # error: "Unsound `yield`: `Any` is not a subtype of `int`" yield returns_any() ``` This rule works especially well when combined with ty's `missing-type-argument` and `unsound-assignment` rules, as well as the Ruff rules [`ANN201`][ann201], [`ANN202`][ann202], [`ANN204`][ann204], [`ANN205`][ann205], and [`ANN206`][ann206]. Enabling all these rules at once effectively makes it much less likely that a `yield` expression can lead to unsoundness "leaking" out of a function unless that function has been *explicitly* annotated with a dynamic type in some way (`-> Generator[Any]` or `-> Generator[tuple[Any]]`, for example). ## Examples ```py from typing import Any, Iterator def returns_any() -> Any: return "foo" def any_iterator() -> Iterator[Any]: yield "foo" def integers() -> Iterator[int]: # error: "Unsound `yield`: `Any` is not a subtype of `int`" yield returns_any() # error: "Unsound `yield from`: `Any` is not a subtype of `int`" yield from any_iterator() ``` Narrow the value before yielding it to fix the diagnostics: ```py from typing import Any, Iterator def returns_any() -> Any: return 42 def any_iterator() -> Iterator[Any]: yield "foo" def integers() -> Iterator[int]: value = returns_any() assert isinstance(value, int) yield value for value in any_iterator(): assert isinstance(value, int) yield value ``` ## Default level This rule is disabled by default. It is intended for users who want stricter soundness checks at generator boundaries. ## See also - `unsound-return-statement` is a similar rule that triggers on unsound `return` statements rather than unsound `yield` expressions - `unsound-assignment` is a similar rule that triggers on unsound assignments [ann201]: https://docs.astral.sh/ruff/rules/missing-return-type-undocumented-public-function/ [ann202]: https://docs.astral.sh/ruff/rules/missing-return-type-private-function/ [ann204]: https://docs.astral.sh/ruff/rules/missing-return-type-special-method/ [ann205]: https://docs.astral.sh/ruff/rules/missing-return-type-static-method/ [ann206]: https://docs.astral.sh/ruff/rules/missing-return-type-class-method/ [assignable]: https://typing.python.org/en/latest/spec/glossary.html#term-assignable [fully-static]: https://typing.python.org/en/latest/spec/glossary.html#term-fully-static-type [subtype]: https://typing.python.org/en/latest/spec/glossary.html#term-subtype # unsupported-base Default level: warn | Stable (since 0.0.1-alpha.7) ## What it does Checks for class definitions that have bases which are unsupported by ty. ## Why is this bad? If a class has a base that is an instance of a complex type such as a union type, ty will not be able to resolve the [method resolution order] (MRO) for the class. This will lead to an inferior understanding of your codebase and unpredictable type-checking behavior. ## Examples ```python import datetime class A: ... class B: ... if datetime.date.today().weekday() != 6: C = A else: C = B class D(C): ... # error: [unsupported-base] ``` [method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order # unsupported-bool-conversion Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for bool conversions where the object doesn't correctly implement `__bool__`. ## Why is this bad? If an exception is raised when you attempt to evaluate the truthiness of an object, using the object in a boolean context will fail at runtime. ## Examples ```python class NotBoolable: __bool__ = None def __lt__(self, other: object) -> "NotBoolable": return self b1 = NotBoolable() b2 = NotBoolable() # exception raised here if b1: # error pass # exception raised here b1 and b2 # error # exception raised here not b1 # error # A chained comparison converts the result of `b1 < b2` to bool. # exception raised here b1 < b2 < b1 # error ``` # unsupported-dynamic-base Default level: ignore | Stable (since 0.0.12) ## What it does Checks for dynamic class definitions (using `type()`) that have bases which are unsupported by ty. This is equivalent to `unsupported-base` but applies to classes created via `type()` rather than `class` statements. ## Why is this bad? If a dynamically created class has a base that is an unsupported type such as `type[T]`, ty will not be able to resolve the [method resolution order] (MRO) for the class. This may lead to an inferior understanding of your codebase and unpredictable type-checking behavior. ## Default level This rule is disabled by default because it will not cause a runtime error, and may be noisy on codebases that use `type()` in highly dynamic ways. ## Examples ```python class Base: ... def factory(base: type[Base]) -> type: # `base` has type `type[Base]`, not `type[Base]` itself return type("Dynamic", (base,), {}) # error: [unsupported-dynamic-base] ``` [method resolution order]: https://docs.python.org/3/glossary.html#term-method-resolution-order # unsupported-operator Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for binary expressions, comparisons, and unary expressions where the operands don't support the operator. ## Why is this bad? Attempting to use an unsupported operator will raise a `TypeError` at runtime. ## Examples ```python class A: ... # TypeError: unsupported operand type(s) for +: 'A' and 'A' A() + A() # error ``` # unused-awaitable Default level: warn | Stable (since 0.0.21) ## What it does Checks for awaitable objects (such as coroutines) used as expression statements without being awaited. ## Why is this bad? Calling an `async def` function returns a coroutine object. If the coroutine is never awaited, the body of the async function will never execute, which is almost always a bug. Python emits a `RuntimeWarning: coroutine was never awaited` at runtime in this case. ## Examples ```python async def fetch_data() -> str: return "data" async def main() -> None: # Warning: coroutine is not awaited fetch_data() # error await fetch_data() # OK ``` # unused-ignore-comment Default level: warn | Stable (since 0.0.1-alpha.1) ## What it does Checks for `ty: ignore` directives that are no longer applicable. ## Why is this bad? A `ty: ignore` directive that no longer matches any diagnostic violations is likely included by mistake, and should be removed to avoid confusion. ## Examples ```py # error a = 20 / 2 # ty: ignore[division-by-zero] ``` Use instead: ```py a = 20 / 2 ``` # unused-type-ignore-comment Default level: warn | Stable (since 0.0.14) ## What it does Checks for `type: ignore` directives that are no longer applicable. ## Why is this bad? A `type: ignore` directive that no longer matches any diagnostic violations is likely included by mistake, and should be removed to avoid confusion. ## Examples ```py # error a = 20 / 2 # type: ignore ``` Use instead: ```py a = 20 / 2 ``` ## Options This rule is skipped if [`analysis.respect-type-ignore-comments`](https://docs.astral.sh/ty/reference/configuration/#respect-type-ignore-comments) is set to `false`. # useless-overload-body Default level: warn | Stable (since 0.0.1-alpha.22) ## What it does Checks for various `@overload`-decorated functions that have non-stub bodies. ## Why is this bad? Functions decorated with `@overload` are ignored at runtime; they are overridden by the implementation function that follows the series of overloads. While it is not illegal to provide a body for an `@overload`-decorated function, it may indicate a misunderstanding of how the `@overload` decorator works. ## Example ```toml [environment] python-version = "3.11" ``` ```py from typing import overload @overload def foo(x: int) -> int: # will never be executed return x + 1 # error @overload def foo(x: str) -> str: # will never be executed return "Oh no, got a string" # error def foo(x: int | str) -> int | str: raise Exception("unexpected type encountered") ``` Use instead: ```py from typing import assert_never, overload @overload def foo(x: int) -> int: ... @overload def foo(x: str) -> str: ... def foo(x: int | str) -> int | str: if isinstance(x, int): return x + 1 elif isinstance(x, str): return "Oh no, got a string" else: assert_never(x) ``` ## References - [Python documentation: `@overload`](https://docs.python.org/3/library/typing.html#typing.overload) # zero-stepsize-in-slice Default level: error | Stable (since 0.0.1-alpha.1) ## What it does Checks for a step size of zero in slices when the operation is known to fail. ## Why is this bad? Python's built-in sequence types raise a `ValueError` when sliced with a step size of zero. ## Known problems This check is not exhaustive. It reports zero-step slices for certain built-in sequence types where the operation is known to fail. A custom `__getitem__` implementation can accept or reject such a slice, so ty cannot detect every runtime failure. ## Examples ```python values = list(range(10)) # ValueError: slice step cannot be zero values[1:10:0] # error tuple_values = (1, 2, 3) # ValueError: slice step cannot be zero tuple_values[1:10:0] # error ``` test python_environment::unix_system_installation_with_no_lib_directory ... ok test python_environment::lib64_site_packages_directory_on_unix ... ok test rule::rule_no_selector ... ok test python_environment::pyvenv_cfg_file_annotation_no_trailing_newline ... ok test rule::preview_rule_status ... ok test python_environment::python_cli_argument_system_installation ... ok test python_environment::src_subdirectory_takes_precedence_over_repo_root ... ok test python_environment::src_subdirectory_not_added_as_root_if_src_package_exists ... ok test python_environment::python_cli_argument_virtual_environment ... ok test rule_selection::cli_all_rules_warn ... ok test rule_selection::cli_specific_then_all ... ok test python_environment::many_search_paths ... ok test file_selection::force_exclude_project_under_excluded_directory ... ok test python_environment::pyvenv_cfg_file_annotation_showing_where_python_version_set ... ok test rule_selection::all_overrides ... ok test rule_selection::configuration_all_rules ... ok test rule_selection::cli_unknown_rules ... ok test rule_selection::cli_all_rules_ignore ... ok test rule_selection::cli_all_rules_precedence ... ok test python_environment::defaults_to_a_new_python_version ... ok test rule_selection::overrides_invalid_exclude_glob ... ok test python_environment::python_argument_trapped_in_a_symlink_factory ... ok test python_environment::pythonpath_multiple_dirs_is_respected ... ok test rule_selection::configuration_all_rules_with_rule_sorting_before_all ... ok test rule_selection::overrides_basic ... ok test rule_selection::overrides_invalid_include_glob ... ok test rule_selection::overrides_empty_include ... ok test rule_selection::configuration_unknown_rules ... ok test file_selection::explicit_path_overrides_exclude_force_exclude ... ok test rule_selection::overrides_exclude ... ok test rule_selection::overrides_all_rules_with_rule_sorting_before_all ... ok test scripts::configured_source_roots_and_extra_paths_are_relative_to_the_script ... ok test rule_selection::multiple_overrides_inherit_cli_rules ... ok test python_environment::python_version_inferred_from_system_installation ... ok test python_environment::pythonpath_is_respected ... ok test rule_selection::overrides_missing_include_exclude ... ok test rule_selection::overrides_no_actual_overrides ... ok test rule_selection::overrides_precedence ... ok test rule_selection::cli_rule_severity ... ok test rule_selection::cli_rule_severity_precedence ... ok test rule_selection::overrides_inherit_global ... ok test scripts::invalid_script_environment_reports_configuration_error ... ok test scripts::disabled_integration_does_not_initialize_scripts ... ok test rule_selection::overrides_unknown_rules ... ok test scripts::excluded_scripts_do_not_initialize_their_environments ... ok test sarif_diagnostics ... ok test scripts::invalid_script_settings_report_configuration_error ... ok test scripts::cli_arguments_override_script_environment ... ok test scripts::inherited_file_settings_are_relative_to_the_script ... ok test scripts::explicit_config_replaces_the_script_environment ... ok test scripts::invalid_python_requirement_reports_configuration_error ... ok test scripts::invalid_script_search_paths_do_not_blame_python_environment ... ok test scripts::inline_overrides_are_ignored ... ok test scripts::environment_options ... ok test scripts::cli_arguments_override_script_options ... ok test scripts::invalid_toml_reports_configuration_error ... ok test scripts::scripts_do_not_use_an_inactive_project_environment ... ok test scripts::project_settings_and_overrides_do_not_apply ... ok test scripts::inline_settings_override_user_configuration ... ok test scripts::unknown_rule_diagnostics_point_to_script_metadata ... ok test scripts::explicit_config_replaces_inline_metadata ... ok test scripts::scripts_use_an_activated_virtual_environment ... ok test scripts::ordinary_files_do_not_initialize_scripts ... ok test scripts::scripts_have_no_implicit_first_party_roots ... ok test scripts::project_search_paths_do_not_apply_to_scripts ... ok test scripts::invalid_metadata_options_report_configuration_error ... ok test scripts::metadata_without_tool_ty_uses_default_settings ... ok test scripts::unavailable_uv_reports_metadata_error ... ok test scripts::inline_terminal_settings_do_not_apply ... ok test scripts::python_requirement_overrides_user_configuration ... ok test server::find_rejects_broken_symlink ... ok test rule_selection::configuration_rule_severity ... ok test server::find_follows_symlinks ... ok test server::find_rejects_non_executable_file ... ok test server::find_rejects_wrong_layout ... ok test scripts::script_version_and_platform_are_isolated_from_project_configuration ... ok test server::find_rejects_directory ... ok test server::find_does_not_fall_back_from_configured_environment ... ok test scripts::user_configuration_applies ... ok test server::find_uses_cwd_when_project_discovery_fails ... ok test scripts::shared_imports_use_each_scripts_platform ... ok test server::find_uses_configured_interpreter ... ok test server::find_uses_discovered_project_root ... ok test server::find_uses_configured_environment ... ok test server::find_returns_no_match_on_python_environment_error ... ok test test_run_in_sub_directory ... ok test test_include_hidden_files_by_default ... ok test python_environment::check_venv_resolution_with_working_venv ... ok test scripts::verbose_rule_diagnostics_identify_script_metadata ... ok test scripts::python_version_diagnostics_identify_script_metadata ... ok test test_output_format_env ... ok test python_environment::check_venv_resolution_without_working_venv ... ok test test_respect_ignore_files ... ok test uv_workspace::scripts_only_mode_disables_uv_workspace_discovery ... ok test scripts::uv_metadata::failed_uv_script_synchronization_reports_an_error ... ok test user_configuration ... ok test uv_workspace::uv_workspace_discovery_is_opt_in ... ok test uv_workspace::external_workspace_member_uses_workspace_configuration ... ok test uv_workspace::finds_uv_on_path_without_uv_environment_variable ... ok test uv_workspace::forwards_active_environment_to_uv ... ok test uv_workspace::explicit_config_file_uses_uv_environment_and_ty_rules ... ok test uv_workspace::explicit_ordinary_file_uses_uv_workspace_discovery ... ok test scripts::uv_metadata::workspace_dependencies_do_not_apply_to_scripts ... ok test uv_workspace::explicit_workspace_member_directory_uses_workspace_configuration ... ok test uv_workspace::indirect_dependencies_use_updated_declarations ... ok test uv_workspace::multiple_explicit_files_use_uv_workspace_discovery ... ok test scripts::uv_metadata::indirect_dependencies_use_script_declarations ... ok test uv_workspace::indirect_dependencies_use_uv_module_ownership ... ok test uv_workspace::selected_workspace_member_excludes_nested_member ... ok test uv_workspace::explicit_script_path_disables_uv_workspace_discovery ... ok test uv_workspace::uses_requires_python_with_uv_workspace ... ok test uv_workspace::warns_when_uv_workspace_metadata_cannot_be_loaded ... ok test test_quiet_output ... ok test uv_workspace::uses_uv_workspace_root_without_checking_siblings ... ok test uv_workspace::overridden_python_environment_disables_dependency_checks ... ok test scripts::uv_metadata::uses_uv_script_environment_and_python_version ... ok test scripts::uv_metadata::synchronizes_multiple_scripts_with_one_worker ... ok test scripts::uv_metadata::fixes_script_using_uv_environment ... ok test scripts::uv_metadata::imported_script_environment ... ok test scripts::uv_metadata::synchronizes_imported_script_with_one_worker ... ok test scripts::uv_metadata::cli_python_selects_script_interpreter_without_replacing_its_environment ... ok test result: ok. 220 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.48s Running tests/file_watching.rs (ruff/target/debug/deps/file_watching-f9e1d05abfba68e0) running 81 tests test hard_links_to_target_outside_project ... ignored, inotify doesn't support observing changes to hard linked files. test deleted_file ... ok test nested_project_config_change_is_cheap_if_active_project_unchanged ... ok test directory_deleted ... ok test nested_projects_delete_root ... ok test move_file_to_trash ... ok test changed_file ... ok test directory_renamed ... ok test hard_links_in_project ... ok test changed_versions_file ... ok test active_project_config_change_reloads_project ... ok test directory_moved_to_trash ... ok test directory_moved_to_project ... ok test move_file_to_project ... ok test new_directory_with_python_files ... ok test ignore_file_change_reloads_files_not_project_metadata ... ok test add_search_path ... ok test changes_to_config_file_override ... ok test rename_files_casing_only ... ignored test new_file_in_parent_ignored_directory ... ok test changes_to_user_configuration ... ok test new_file_in_ignored_directory ... ok test new_ignore_file_in_ignored_directory ... ok test new_non_project_file ... ok test new_files_with_explicit_included_paths ... ok test new_file ... ok test new_file_in_included_out_of_project_directory ... ok test new_ignored_file ... ok test explicitly_included_file_remains_checked_when_becoming_a_script ... ok test nested_search_path_picks_up_missed_dependency_edit ... ok test new_non_python_file_is_not_indexed ... ok test creating_site_packages_after_metadata_updates_inferred_python_version ... ok test rename_file ... ok test moving_configured_interpreter_parent_into_project_updates_inferred_python_version ... ok test external_interpreter_changes_update_inferred_python_version ... ok test project_reload_preserves_override_options ... ok test project_reload_preserves_fallback_options ... ok test reloading_options_updates_inferred_python_version_diagnostics_when_metadata_is_unchanged ... ok test change_python_version_and_platform ... ok test search_path ... ok test unix::changed_metadata ... ok test unix::symlink_inside_project ... ok test submodule_cache_invalidation_created ... ok test submodule_cache_invalidation_deleted ... ok test pth_edit_while_unwatched_watches_new_search_path ... ok test script_dependency_changes ... ok test unix::symlinked_module_search_path ... ok test repairing_activated_environment_updates_inferred_python_version ... ok test src_file_filter_change_reloads_project_files ... ok test restoring_script_metadata_rewatches_search_path ... ok test submodule_cache_invalidation_created_then_deleted ... ok test scripts_to_synchronize_after_file_and_directory_changes ... ok test recreating_default_environment_updates_inferred_python_version ... ok test repairing_default_environment_updates_inferred_python_version ... ok test submodule_cache_invalidation_after_pyproject_created ... ok test remove_search_path ... ok test unix::symlink_target_outside_watched_paths ... ok test script_exclusion_tracks_file_creation_and_metadata_edits ... ok test unix::symlinked_site_packages_outside_environment ... ok test shared_script_search_paths_remain_watched_until_unused ... ok test uv_metadata::unchanged_script_environment_is_reused_after_source_edits ... ok test uv_metadata::script_pth_adds_watched_search_path ... ok test uv_metadata::creating_lockfile_does_not_request_uv_metadata_when_uv_is_disabled ... ok test uv_metadata::creating_directory_in_excluded_search_path_does_not_request_uv_metadata ... ok test uv_metadata::creating_uv_toml_refreshes_workspace_members ... ok test uv_metadata::creating_python_version_file_refreshes_workspace_members ... ok test uv_metadata::creating_pyproject_toml_with_config_override_clears_uv_error ... ok test uv_metadata::moving_missing_member_into_workspace_outside_checked_paths_clears_uv_error ... ok test uv_metadata::editing_then_moving_a_file_out_does_not_request_uv_metadata ... ok test uv_metadata::moving_required_member_out_reports_uv_error ... ok test uv_metadata::deleting_excluded_workspace_dependency_reports_uv_error ... ok test uv_metadata::uv_pip_uninstall_reports_import_and_metadata_errors ... ok test uv_metadata::updating_workspace_lockfile_outside_project_checks_new_member_dependencies ... ok test uv_metadata::removing_tool_ty_section_checks_workspace_files ... ok test uv_metadata::removing_dependency_from_nested_pyproject_toml_reports_missing_dependency ... ok test uv_metadata::recreating_selected_environment_clears_uv_error ... ok test uv_metadata::project_refresh_applies_settings_despite_uv_errors ... ok test uv_metadata::uv_pip_install_clears_import_and_metadata_errors ... ok test uv_metadata::corrected_script_dependencies_replace_initialization_errors ... ==> ERROR: Build failed, check /home/alhp/workspace/chroot/build_777ac516-2714-4bbe-a702-ea0a74945019/build