-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[ty] Add more random TypeDetails and tests #21546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| let mut f = f.with_detail(TypeDetail::Type(self.ty)); | ||
| f.write_str("<class '")?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is theoretically useless because the span logic will prefer the inner class.display_with but this is effectively a fallback if it doesn't.
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
| SubclassOfInner::Dynamic(dynamic) => { | ||
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) | ||
| .write_str("type")?; | ||
| f.write_char('[')?; | ||
| write!(f, "{dynamic}")?; | ||
| f.write_char(']') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this invoke the Any/Unknown special cases? (Should that logic be factored out?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this invoke the Any/Unknown special cases?
I think so, yes!
Should that logic be factored out?
Sure!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in fact, maybe that logic should just be moved to Type::definition() in types.rs?
|
AlexWaygood
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) | ||
| .write_str("type")?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually not totally sold that double-clicking on type in type[int] should take you anywhere, because type isn't a generic class in the same way as list[int] or dict[str, str]. Though it is true that all type[] types are instances of type
If we do want it to take you somewhere, though, it should take you to builtins.type rather than typing.Type, so that would be
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) | |
| .write_str("type")?; | |
| f.with_detail(TypeDetail::Type(KnownClass::Type.to_class_literal(self.db))) | |
| .write_str("type")?; |
| } | ||
| SubclassOfInner::Class(ClassType::Generic(alias)) => { | ||
| f.write_str("type[")?; | ||
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) | |
| f.with_detail(TypeDetail::Type(KnownClass::Type.to_class_literal(self.db))) |
| f.write_char(']') | ||
| } | ||
| SubclassOfInner::Dynamic(dynamic) => { | ||
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and here
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) | |
| f.with_detail(TypeDetail::Type(KnownClass::Type.to_class_literal(self.db))) |
| SubclassOfInner::Dynamic(dynamic) => { | ||
| f.with_detail(TypeDetail::Type(Type::SpecialForm(SpecialFormType::Type))) | ||
| .write_str("type")?; | ||
| f.write_char('[')?; | ||
| write!(f, "{dynamic}")?; | ||
| f.write_char(']') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this invoke the Any/Unknown special cases?
I think so, yes!
Should that logic be factored out?
Sure!
…d-typevar * origin/main: (24 commits) [ty] Remove brittle constraint set reveal tests (#21568) [`ruff`] Catch more dummy variable uses (`RUF052`) (#19799) [ty] Use the same snapshot handling as other tests (#21564) [ty] suppress autocomplete suggestions during variable binding (#21549) Set severity for non-rule diagnostics (#21559) [ty] Add `with_type` convenience to display code (#21563) [ty] Implement docstring rendering to markdown (#21550) [ty] Reduce indentation of `TypeInferenceBuilder::infer_attribute_load` (#21560) Bump 0.14.6 (#21558) [ty] Improve debug messages when imports fail (#21555) [ty] Add support for relative import completions [ty] Refactor detection of import statements for completions [ty] Use dedicated collector for completions [ty] Attach subdiagnostics to `unresolved-import` errors for relative imports as well as absolute imports (#21554) [ty] support PEP 613 type aliases (#21394) [ty] More low-hanging fruit for inlay hint goto-definition (#21548) [ty] implement `TypedDict` structural assignment (#21467) [ty] Add more random TypeDetails and tests (#21546) [ty] Add goto for `Unknown` when it appears in an inlay hint (#21545) [ty] Add type definitions for `Type::SpecialForm`s (#21544) ...
No description provided.