[ty] Respect the gradual guarantee when reporting errors in resolving MROs#17962
Merged
AlexWaygood merged 2 commits intomainfrom May 8, 2025
Merged
[ty] Respect the gradual guarantee when reporting errors in resolving MROs#17962AlexWaygood merged 2 commits intomainfrom
AlexWaygood merged 2 commits intomainfrom
Conversation
Contributor
|
dcreager
added a commit
that referenced
this pull request
May 8, 2025
* main: [ty] Respect the gradual guarantee when reporting errors in resolving MROs (#17962) Convert `Message::SyntaxError` to use `Diagnostic` internally (#17784) [ty] Support extending `__all__` with a literal tuple or set as well as a literal list (#17948) [ty] Make `unused-ignore-comment` disabled by default for now (#17955) [ty] Change default severity for `unbound-reference` to `error` (#17936) [ty] Ignore `possibly-unresolved-reference` by default (#17934) [ty] Default to latest supported python version (#17938) [ty] Generate and add rules table (#17953) Update the schemastore script to match changes in ty (#17952) [ty] Implement `global` handling and `load-before-global-declaration` syntax error (#17637)
dcreager
added a commit
that referenced
this pull request
May 8, 2025
* dcreager/default-typevars: clean up the diff remove trait track in type again clippy Better expansion of default typevars specialize_partial enum for TypeMapping [ty] Respect the gradual guarantee when reporting errors in resolving MROs (#17962) Specialize trait Convert `Message::SyntaxError` to use `Diagnostic` internally (#17784) [ty] Support extending `__all__` with a literal tuple or set as well as a literal list (#17948) [ty] Make `unused-ignore-comment` disabled by default for now (#17955) [ty] Change default severity for `unbound-reference` to `error` (#17936) [ty] Ignore `possibly-unresolved-reference` by default (#17934) [ty] Default to latest supported python version (#17938) [ty] Generate and add rules table (#17953) Update the schemastore script to match changes in ty (#17952) [ty] Implement `global` handling and `load-before-global-declaration` syntax error (#17637)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
If you have code like this:
then we issue a complaint about this, because both bases are inferred as
Unknown. The duplicate bases mean that we cannot resolve a consistent Method Resolution Order for the class:This violates the gradual guarantee: if either
Unknownwere replaced with a fully static type, the error might go away. There's a long-standing TODO question about our behaviour in our tests here:ruff/crates/ty_python_semantic/resources/mdtest/mro.md
Lines 395 to 411 in 981bd70
And I keep seeing
[inconsistent-mro]errors in mypy_primer reports. So I think it is time that we do, indeed, revisit this and properly respect the gradual guarantee.This PR switches things so that we do not report a diagnostic for unresolvable MROs if the reason for the MRO being unresolvable is that there are duplicate bases and the duplicate base in question is a dynamic type (
Todo,AnyorUnknown). We now silently fallback to an MRO of<the class in question>, Unknown, objectin such cases, without reporting a diagnostic.Test Plan
cargo test -p ty_python_semantic