[ty] Add NewTypes to the property tests#24113
Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 85.38%. The percentage of expected errors that received a diagnostic held steady at 78.70%. The number of fully passing files held steady at 64/132. |
Memory usage reportMemory usage unchanged ✅ |
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-await |
0 | 40 | 0 |
invalid-return-type |
0 | 1 | 0 |
| Total | 0 | 41 | 0 |
Changes in flaky projects detected. Raw diff output excludes flaky projects; see the HTML report for details.
20f2deb to
e32d96b
Compare
| let db = CACHED_DB.get_or_init(|| { | ||
| let db = TestDbBuilder::new() | ||
| .with_file( | ||
| NEWTYPE_MODULE_PATH, | ||
| "\ | ||
| from typing import NewType | ||
|
|
||
| NewTypeOfInt = NewType('NewTypeOfInt', int) | ||
| NewTypeOfFloat = NewType('NewTypeOfFloat', float) | ||
| NewTypeOfComplex = NewType('NewTypeOfComplex', complex) | ||
| NewTypeOfStr = NewType('NewTypeOfStr', str)", | ||
| ) | ||
| .build() | ||
| .unwrap(); | ||
| Arc::new(Mutex::new(db)) | ||
| }); |
There was a problem hiding this comment.
Ah, nice. I should have done that for other examples as well. That will also be useful for things like TypedDicts. I think we could maybe consider making that setup more general (in the sense that we could rename that module to just type_candidates.py or similar), or do you see any advantage from having multiple files (one for newtype candidates, one for typeddict candidates, …)
There was a problem hiding this comment.
Yes, making it a consolidated source file makes sense! I'll rename it.
That will also be useful for things like TypedDicts.
Yes -- though for TypedDicts, we can also use a similar strategy to what we use for Callables, since (unlike NewTypes) we're able to create synthesized TypedDicts with no source definition. An advantage of using synthesized TypedDicts would be increased randomness; a disadvantage would be... increased randomness. (If we have the property tests select from fixed TypedDicts in a source file, we know it's more likely to pick an "interesting" TypedDict when it does pick a TypedDict). Possibly a combination of the two strategies might work well for TypedDicts and Protocols?
e32d96b to
74a08a1
Compare
* main: (36 commits) [ty] Reduce diagnostic range for `invalid-metaclass` (#24145) [ty] Simplify TypeVar assignability/subtyping logic (#24138) [ty] Prevent tainted loop bindings in cycle normalization (#24143) [ty] Add precisely-typed overloads for `TypedDict` update (#24101) [ty] Fix folding ranges of comments separated by statements (#24132) Bump ecosystem-analyzer pin (#24136) Bump ecosystem-analyzer pin (#24135) Simplify `NewType` handling in `relation.rs` (#24109) [ty] Add more tests for `NewType` subtyping (#24115) [ty] Add `NewType`s to the property tests (#24113) [ty] Prepare test files for unreachable code change (#24133) `analyze graph`: resolve string imports that reference attributes, not just modules (#24058) Update Artifact GitHub Actions dependencies (#24116) Update taiki-e/install-action action to v2.68.33 (#24130) Update taiki-e/install-action action to v2.68.32 (#24123) Update Rust crate serde_with to v3.18.0 (#24126) Update Swatinem/rust-cache action to v2.9.1 (#24127) Update Rust crate quick-junit to 0.6.0 (#24125) Update Rust crate clap to v4.6.0 (#24124) Update Rust crate tracing-subscriber to v0.3.23 (#24122) ...
Summary
This should give us more confidence when refactoring
NewType-related code inrelation.rsTest Plan
I ran
QUICKCHECK_TESTS=1000000 cargo test --profile=profiling -p ty_python_semantic -- --ignored types::property_tests::stableand didn't observe any failures