Skip to content
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

[red-knot] Outline integration point for len diagnostics #16124

Draft
wants to merge 2 commits into
base: micha/call-outcome-step1
Choose a base branch
from

Conversation

MichaReiser
Copy link
Member

Summary

This step continues with what the first PR started by moving out type checking operations from the Type:: operations.

I found len an interesting use case because it may lead to a fair amount of code duplication.

I'm still not a 100% convinced by this approach because it can require performing some operations twice:

  1. When infering the return type of the call
  2. When checking the call itself

We could avoid some of that by adding more information to the Outcome but I'm not too much a fan of that
because it means larger return types for everyone.

Test Plan

@@ -3344,6 +3344,10 @@ impl<'db> TypeInferenceBuilder<'db> {
};
}
}

KnownFunction::Len => {
// TODO: Assert that the argument implements the `Sized` protocol (correctly).
Copy link
Member Author

Choose a reason for hiding this comment

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

This probably requires calling __len__ to get the CallDunderLenOutcome and then verify the binding on it.

@AlexWaygood AlexWaygood added the red-knot Multi-file analysis & type inference label Feb 12, 2025
match self.call_dunder(db, "__len__", &CallArguments::positional([*self])) {
CallDunderOutcome::MethodNotAvailable => CallDunderLenOutcome::MethodNotAvailable,
CallDunderOutcome::Call(outcome) => CallDunderLenOutcome::Call(outcome),
CallDunderOutcome::PossiblyUnbound(outcome) => {
Copy link
Member Author

Choose a reason for hiding this comment

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

What's slightly confusing here is that CallOutcome also has a PossiblyUnbound variant which can also be in the Call variant. I feel like we should only have one?

@MichaReiser MichaReiser force-pushed the micha/call-outcome-step2 branch from 4c984a1 to 0232257 Compare February 12, 2025 17:47
@MichaReiser MichaReiser force-pushed the micha/call-outcome-step2 branch from 0232257 to 20cfc11 Compare February 12, 2025 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants