Skip to content

Track spans and TypeTrace when relating unbound type variables in type inferencer #16847

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

Closed
nikomatsakis opened this issue Aug 29, 2014 · 5 comments
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

The new type inferencer in PR #15955 does not track spans as precisely as it could. When two unbound type variables are related to one another, it records the relation (subtype, supertype, equality) but does not record the reason that the relation exists (i.e., the associated span and TypeTrace). When one of those two variables is later bound to a specific type T, the other will also be bound to a type U (derived from T) and T and U will be related -- but this relation will use the current span and TypeTrace, rather than the original span. The primary side-effect of this is that the output from a "cannot infer" message will be more confusing -- but given that that output is already pretty useless, I was unable to get a good example.

@nikomatsakis
Copy link
Contributor Author

On a related note, we don't give a very descriptive origin to type variables created when generalizing from T to U (in that example).

@steveklabnik steveklabnik added the A-type-system Area: Type system label Jan 27, 2015
@steveklabnik
Copy link
Member

@nikomatsakis is this still relevant today?

@nikomatsakis
Copy link
Contributor Author

On Tue, Feb 02, 2016 at 10:40:33AM -0800, Steve Klabnik wrote:

@nikomatsakis is this still relevant today?

Yes.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 21, 2017
@steveklabnik
Copy link
Member

Triage: not aware of any changes, but then again, I wouldn't be

@Noratrieb Noratrieb added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue. labels Apr 5, 2023
@lcnr
Copy link
Contributor

lcnr commented Aug 8, 2023

Given that there isn't an associated test for this issue and I don't consider it to be actionable, I am closing this.

@lcnr lcnr closed this as completed Aug 8, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 17, 2024
Distinguish integration tests from crates in test explorer

Fix part of rust-lang#16827
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants