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

Demotion to const ptr leads to confusing error message #2949

Closed
jruderman opened this issue Jul 18, 2012 · 8 comments
Closed

Demotion to const ptr leads to confusing error message #2949

jruderman opened this issue Jul 18, 2012 · 8 comments
Labels
A-type-system Area: Type system

Comments

@jruderman
Copy link
Contributor

fn main()
{
    let mut x = ~mut 3;
    assert *x == 3;
    *x = 4;
    assert *x == 4;
    x = ~5;
    assert *x == 5;
}

gives me a somewhat confusing error

1.rs:5:4: 5:6 error: assigning to dereference of const ~ pointer
1.rs:5     *x = 4;
           ^~

Took me a while to figure out that the last assignment was forcing x to become a const ptr for its entire life. That was my mistake, but causing an error earlier in the function threw me off. It would be nice if the compiler explained why the type of x was not what it appeared to be.

@nikomatsakis
Copy link
Contributor

Basically what would have to happen, I think, is that the inference engine remembers all types that influenced the final result and prints them out.

@bblum
Copy link
Contributor

bblum commented Jul 18, 2012

Maybe stratify checking on assignments and dereferences? Really the error you want to see is "assignment to x of wrong type".

@nikomatsakis
Copy link
Contributor

This is sort of an unsolvable problem. We don't want to say that the type of a variable is precisely equal to its first assignment. Imagine, for example, that we implement the "case class" proposal and therefore some and none are types. Then a program like this:

let mut x = none;
...
x = some(3);

would be illegal. But at the same time there are a series of conflicting constraints. Right now we take the ML approach and print a message at the point we detect the inconsistency. This is probably fine, but where we go wrong is that we (like every other type-inferring language I've used) choose to blame the point where we detected the inconsistency, when really the incorrect statement could be any of the statements that contribute. So probably the best we can do is identify the contradictory constraints and the statements which led to them, and let the user decide which one is wrong.

@nikomatsakis
Copy link
Contributor

To put it another way, if there were no *x = ... line, the type inferencer would be doing exactly the right thing here by inferring ~const int.

@brson
Copy link
Contributor

brson commented Apr 22, 2013

Updated test case

fn main()
{
    let mut a = 3;
    let mut x = &mut a;
    assert!(*x == 3);
    *x = 4;
    assert!(*x == 4);
    let a = 3;
    x = &a;
    assert!(*x == 5);
}

@nikomatsakis
Copy link
Contributor

I have been wanting to do an experiment of switching to a standard unification-based inference scheme rather than the current one which tries to reason about subtyping. This will be a mixed bag, because the current one handles some cases correctly, but it would also solve this particular problem.

@emberian
Copy link
Member

emberian commented Jul 7, 2013

Still relevant

@huonw
Copy link
Member

huonw commented Oct 18, 2013

Triage: const pointers have been removed, closing.

@huonw huonw closed this as completed Oct 18, 2013
RalfJung pushed a commit to RalfJung/rust that referenced this issue Jul 8, 2023
cronjob auto-PR: fetch more of the history
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
Projects
None yet
Development

No branches or pull requests

6 participants