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.

Sign up for GitHub

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

Jump to bottom

freeze type vars after structure is extracted #2262

Closed
nikomatsakis opened this issue Apr 20, 2012 · 6 comments
Closed

freeze type vars after structure is extracted #2262

nikomatsakis opened this issue Apr 20, 2012 · 6 comments
Assignees
@nikomatsakis
Labels
A-type-system Area: Type system C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@nikomatsakis
Copy link
Contributor

I'm pretty sure that it is possible for the following things to happen today:

  1. We infer a type with bounds X <: T <: top
  2. We resolve T structurally based on X
  3. T acquires an upper bound and perhaps migrates away

I don't have a specific bad example, but I think it could lead to inconsistencies, perhaps with impl dispatch, perhaps elsewhere. This issue is kind of a note to myself to come up with some examples and make some tests and be sure we're ok. I think what it amounts to is that whenever we do a type-dependent operation, we should go back and assert this type as the upper-bound, so that the type inferencer doesn't come away with a more liberal upper-bound.

Our quite limited subtyping might also make this less relevant.
@ghost ghost assigned nikomatsakis Apr 20, 2012
@graydon
Copy link
Contributor

graydon commented Jun 19, 2013

nominating this to move up to the "well defined" milestone. I don't entirely understand it but it sounds like a question of clear specification at very least.

@graydon
Copy link
Contributor

graydon commented Jun 20, 2013

sub-bug of #6834

@graydon
Copy link
Contributor

graydon commented Jun 20, 2013

accepted for well-defined milestone

@metajack
Copy link
Contributor

metajack commented Aug 8, 2013

visiting for triage. nothing to add.

@flaper87
Copy link
Contributor

visiting for triage, it still seems relevant.

@nikomatsakis
Copy link
Contributor Author

This is no longer relevant, given the new inference strategy wherein we instantiate type variables once and exactly one.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
@bors
Auto merge of rust-lang#2262 - RalfJung:zulip, r=RalfJung
dcaa7a7 
only one Zulip cron job topic per month
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
@bors
Auto merge of rust-lang#10933 - y21:issue2262-followup, r=Centri3
da56c35 
[`useless_vec`]: lint on `vec![_]` invocations that adjust to a slice

Fixes rust-lang#2262 (well, actually my PR over at rust-lang#10901 did do most of the stuff, but this PR implements the one last other case mentioned in the comments that my PR didn't fix)

Before this change, it would lint `(&vec![1]).iter().sum::<i32>()`, but not `vec![1].iter().sum::<i32>()`. This PR handles this case.
This also refactors a few things that I wanted to do in my other PR but forgot about.

changelog: [`useless_vec`]: lint on `vec![_]` invocations that adjust to a slice
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nikomatsakis nikomatsakis

Labels
A-type-system Area: Type system C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@flaper87 @graydon @metajack @nikomatsakis