Skip to content

fix sqlalchemy func.current_timestamp missing doc #2889#2938

Open
asukaminato0721 wants to merge 1 commit into
facebook:mainfrom
asukaminato0721:2889
Open

fix sqlalchemy func.current_timestamp missing doc #2889#2938
asukaminato0721 wants to merge 1 commit into
facebook:mainfrom
asukaminato0721:2889

Conversation

@asukaminato0721

Copy link
Copy Markdown
Contributor

Summary

Fixes #2889

hover now falls back to the docstring of the class object represented by the hover type when the resolved symbol definition itself has no docstring. That covers the @property -> Type[current_timestamp] case from the issue.

Test Plan

add test

@meta-cla meta-cla Bot added the cla signed label Mar 26, 2026
@asukaminato0721 asukaminato0721 marked this pull request as ready for review March 26, 2026 21:59
Copilot AI review requested due to automatic review settings March 26, 2026 21:59
@github-actions

This comment has been minimized.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Improves LSP hover documentation so that when hovering a symbol whose definition lacks a docstring (e.g., a @property returning Type[SomeClass]), the hover can fall back to showing the docstring of the referenced class object type—addressing the missing-doc scenario in issue #2889.

Changes:

  • Add a hover fallback to retrieve docstrings from class-object types when the resolved symbol has no docstring.
  • Add an LSP hover regression test covering @property -> Type[current_timestamp] docstring fallback.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
pyrefly/lib/test/lsp/hover.rs Adds a regression test ensuring hover falls back to the returned class’s docstring for a property returning Type[T].
pyrefly/lib/lsp/wasm/hover.rs Implements fallback docstring lookup for class-object types when the primary definition has no docstring.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +326 to +343
let definition_handle = Handle::new(
qname.module_name(),
qname.module_path().dupe(),
handle.sys_info().dupe(),
);
let definition = transaction
.find_definition(
&definition_handle,
qname.range().start(),
FindPreference {
resolve_call_dunders: false,
..Default::default()
},
)
.into_iter()
.find(|item| item.definition_range == qname.range())?;
Some(Docstring(definition.docstring_range?, definition.module))
}

Copilot AI Mar 26, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docstring_for_class_object_type relies on transaction.find_definition, which hard-depends on get_ast(handle) being present. ASTs can be evicted after computing answers (ModuleState::evict_ast stores None), so this fallback can silently stop working for many library modules even if their exports/types are available.

To make this robust, avoid the find_definition path here (or re-parse the module when get_ast is None). A practical alternative is to fetch the class symbol’s docstring_range directly from the target module’s exports (and follow ExportLocation::OtherModule if needed), which doesn’t require retaining the AST. Also note FindPreference::default() prefers .pyi; for docstrings you likely want to prefer executable .py when available.

Copilot uses AI. Check for mistakes.
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

Copy link
Copy Markdown

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

2 participants