Skip to content

[ty] Add error context for intersection types#24772

Open
sharkdp wants to merge 1 commit intomainfrom
david/intersection-ctx
Open

[ty] Add error context for intersection types#24772
sharkdp wants to merge 1 commit intomainfrom
david/intersection-ctx

Conversation

@sharkdp
Copy link
Copy Markdown
Contributor

@sharkdp sharkdp commented Apr 21, 2026

Summary

This implementation is basically the dual of what we do for unions (with the assignability direction flipped).

Test Plan

Updated mdtests.

@sharkdp sharkdp added the ty Multi-file analysis & type inference label Apr 21, 2026
@astral-sh-bot
Copy link
Copy Markdown

astral-sh-bot Bot commented Apr 21, 2026

Typing conformance results

No changes detected ✅

Current numbers
The percentage of diagnostics emitted that were expected errors held steady at 87.94%. The percentage of expected errors that received a diagnostic held steady at 83.36%. The number of fully passing files held steady at 79/133.

@astral-sh-bot
Copy link
Copy Markdown

astral-sh-bot Bot commented Apr 21, 2026

Memory usage report

Memory usage unchanged ✅

@astral-sh-bot
Copy link
Copy Markdown

astral-sh-bot Bot commented Apr 21, 2026

ecosystem-analyzer results

No diagnostic changes detected ✅

Full report with detailed diff (timing results)

@sharkdp sharkdp force-pushed the david/intersection-ctx branch from 50d382d to 19addde Compare April 21, 2026 17:43
@sharkdp sharkdp force-pushed the david/intersection-ctx branch from 19addde to 5b2f0cc Compare April 21, 2026 17:50
@sharkdp sharkdp marked this pull request as ready for review April 21, 2026 17:52
| |
| Declared type
|
info: no element of intersection `HasBar & HasNeither` is assignable to `SupportsFooAndBar`
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

hmmm... when Protocol types are involved, I don't think it's necessarily true that at least one element of the intersection type must be assignable to the declared type. E.g. this feels like it should be fine?

from typing import Protocol, runtime_checkable

@runtime_checkable
class Foo(Protocol):
    def foo(self): ...

class Bar(Protocol):
    def bar(self): ...

class FooAndBar(Foo, Bar, Protocol): ...

def f(x: Bar):
    if isinstance(x, Foo):
        reveal_type(x)  # Bar & Foo
        y: FooAndBar = x

although... we currently emit a diagnostic on the last line there 🙈 not sure why yet https://play.ty.dev/3d1b9f3f-cbf9-423f-9c0c-495550da8d57

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

astral-sh/ty#338 feels related conceptually

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

not sure why yet

Isn't that the expected behavior based on our implementation of type relations for intersections, which (for assignability from an intersection) is precisely "break it apart and require at least one element to be assignable to the target"?

I don't disagree that Foo & Bar should be assignable to FooAndBar, but to support that we would need to add a new relation arm for intersection vs protocol that is higher priority than the main intersection arm.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

but to support that we would need to add a new relation arm for intersection vs protocol that is higher priority than the main intersection arm.

Right, or just move the existing "anything vs a protocol" arm higher in relation.rs? I can experiment tomorrow

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

Labels

ty Multi-file analysis & type inference

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants