-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[ty] Improve diagnostics when a submodule is not available as an attribute on a module-literal type #21561
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
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
unresolved-attribute |
0 | 0 | 1,858 |
| Total | 0 | 0 | 1,858 |
|
I skimmed the ecosystem results, and couldn't see any false positives where the new diagnostic message was inappropriate. |
crates/ty_python_semantic/resources/mdtest/import/nonstandard_conventions.md
Outdated
Show resolved
Hide resolved
673bf60 to
965e4b5
Compare
| let mut diag = builder.into_diagnostic(format_args!( | ||
| "Submodule `{attr_name}` may not be available as an attribute \ | ||
| on module `{module_name}`" | ||
| )); | ||
| diag.help(format_args!( | ||
| "Consider explicitly importing `{maybe_submodule_name}`" | ||
| )); | ||
| return fallback(); |
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.
if we hit this branch, we have pretty high confidence that we know what the user meant here -- we could even consider inferring the module-literal type of the submodule rather than inferring Unknown. (Or <submodule type> | Unknown...?)
And since this often will (by pure luck!) work at runtime, we could also consider downgrading the diagnostic to warning-level rather than error-level
But either of those would be separate changes from simply improving the diagnostic error message, which is all that this humble PR seeks to achieve.
…ibute on a module-literal type
965e4b5 to
deadc47
Compare
* origin/main: (27 commits) [ty] Add hint about resolved Python version when a user attempts to import a member added on a newer version (#21615) Use release commit for actions/checkout (#21610) [ty] Add failing mdtest for known `Protocol` panic (#21594) [`parser`] Fix panic when parsing IPython escape command expressions (#21480) Fix cargo shear in CI (#21609) Update actions/checkout digest to c2d88d3 (#21601) Update dependency ruff to v0.14.6 (#21603) Update astral-sh/setup-uv action to v7.1.4 (#21602) Update Rust crate clap to v4.5.53 (#21604) Update taiki-e/install-action action to v2.62.56 (#21608) Update Rust crate hashbrown to v0.16.1 (#21605) Update Rust crate indexmap to v2.12.1 (#21606) Update Rust crate syn to v2.0.111 (#21607) [ty] Check method definitions on subclasses for Liskov violations (#21436) [ty] Fix panic for unclosed string literal in type annotation position (#21592) [ty] Fix rendering of unused suppression diagnostic (#21580) [ty] Improve lsp handling of hover/goto on imports (#21572) [ty] Improve diagnostics when a submodule is not available as an attribute on a module-literal type (#21561) [ty] Improve concise diagnostics for invalid exceptions when a user catches a tuple of objects (#21578) [ty] upgrade salsa (#21575) ...
Summary
It's often not obvious to users why we sometimes report
unresolved-attributeerrors for submodules-accessed-on-parent-modules, even though these attributes often are available at runtime (sometimes by sheer luck!). This PR adds a dedicated diagnostic for this case that helps guide the user towards how they can fix the error.Test Plan
Added snapshots