[lsp] Seeing signatures that contain `-> None` when constructing a class is confusing

[rchen152]

See screenshots. If I'm constructing a class or hovering over the name of a class with a custom __init__ method, I see the __init__ signature, which is really nice, but the -> None at the end confused me the first time I saw it, because I thought it was saying that the constructor call returned None. It would be nice if we could replace the None with the class name for display.

[dankondr]

Taking this

[yangdanny97]

In terms of leads @dankondr the feature that we're looking at is called signature help, which shows the signature of the function as you're typing a function call, with a highlighted showing the next parameter

The data for which signatures we show comes from OverloadedCallee traces in answers.rs.

I assume we'd need to detect that it's a constructor call somehow, and transform the return type to be the class.

One interesting edge case would be a call directly to A.__init__(...), which we would probably still want to show as -> None return.

[github-actions]

This issue has someone assigned, but has not had recent activity for more than 2 weeks.

If you are still working on this issue, please add a comment so everyone knows. Otherwise, please unassign yourself and allow someone else to take over.

Thank you for your contributions!

[sgavriil01]

I can take it if it's stale. @yangdanny97 can you assign this to me?

[yangdanny97]

Reassigned, thanks

[sgavriil01]

Constructor Signature Help — Status & Question

Summary

Implemented a display-layer feature that shows class instance type instead of None for constructor calls in signature help.

Example:

• Person() → shows -> Person
• Person.__init__(...) → shows -> None
• foo.method() → unchanged

Implementation

Files modified:

• pyrefly/lib/lsp/wasm/signature_help.rs
• pyrefly/lib/test/lsp/signature_help.rs

Approach:

• Detect constructor calls in get_signature_help_at() by examining source text
• Override return type only for display (no trace storage or type-checking changes)
• Distinguish between Class(), Class.__init__(), and instance.method()

Results

✅ All 24 signature help tests pass
✅ Works on normal Python projects
❌ Stack overflow when analyzing Pyrefly's own codebase (~2000 files)

Crash log:

NFO Prepare to check 2000 files.
thread '' has overflowed its stack
fatal runtime error: stack overflow, aborting

Question

Given that the feature works correctly for typical codebases but crashes on Pyrefly's own complex type stubs, should I:

1. Submit PR with documented limitation
2. Investigate stack overflow further
3. Wait for architectural guidance

@yangdanny97 could you possibly address this issue, is there anything I can do? Can't really understand what's going wrong.

[yangdanny97]

Are you building in release mode or debug mode for that test? You should be using release mode when running Pyrefly on real codebases