The main change here is that I extracted a helper to convert a LSP Position to a TextSize and I then used this logic in to_text_range (which simplifies the code quiet a bit)

Should we implement focus_range and full_range on Type (and return None for types where we don't know it) so we don't have to expose so many type internals?

(Oh, this comment was before I read the full diff; I've seen now the navigation-targets trait. I understand why we want to keep all the trait implementations of that in one place, but it still does feel odd to me that we do that outside of the semantics crate, meaning we have to make so many type internals public.)

I agree that it would be great to avoid exposing these internals. I called this out in the summary that we should introduce a new high level API for all those operations. I'm reluctant to do so just now because it's unclear to me how that API would look like.

I'm getting the sense that we lack two APIs:

• Give a type query its definition: This is roughly what the big match statement does.
• Given a node, query its definition: We'll need this for hover (because most IDEs show the signature and not just the type) and to support some of the goto targets that we currently can't retrieve a type for.

I also don't consider this a problem specific to semantic indexing. Ideally, the LSP and linter would limit their use of salsa APIs (including APIs from ruff_db, e.g. system_path_to_file). But I'm not sure yet how that would look like. I need some more code to identify a pattern.

For example, r-a requires that the ide crate uses its Semantics API

Okay, I have an idea of how to address some of the concerns. But I'll do so in a separate PR

Why not handle this the same as union and collect all navigation targets from elements?

(I think we can ignore negative elements.)

The difference is that the value isn't the type of any of the elements in the intersection. Instead, it's the type that intersects with all elements. So I think it's just wrong? I can try and see what typescript does here

It's the type of all the elements of the intersection; if anything it seems even more correct here than in the union case? In the union case, the actual value only needs to be one of the union elements, the other ones are all "wrong".

TypeScript doesn't support goto type definition on intersections, which matches my understanding unless Red Knot's intersection types work differently.

The LSP shows one location for each union variant, which very nicely matches how unions work: The value is one of the types shown (see screenshot above).

It would be very surprising if we showed intersections exactly the same as unions because users would then be unable to distinguish them from unions. I'll leave this as is (minus filtering out Unknown) because I'm not convinced that presenting them the same as unions is the right solution and there isn't an obvious alternative.

Should this go to the Callable definition in collections.abc? Pyright doesn't do it thought.

Wouldn't that be Goto definition? If so, I thin it should go to type (because this is what to_meta_type returns?

I was referring to a variable that's annotated using typing.Callable similar to how we go to int class for a variable annotated as int. For example, x: Callable[[], None] = lambda: None.

Yeah I think going to the definition of the Callable type for something with a type of Callable would make sense and be consistent with goto-type-definition. But also doesn't really matter until we support navigating to typeshed anyway.