Error for uninitialized vec is unhelpful

[evanmcc]

trying to compile:

fn main() {
    let bar = ["aaaaaa", "bbbbbb", "cccccc"];
    let mut foo: [str];

    for b in bar { foo += [b]; }
}

fails with:

un.rs:9:8: 9:11 error: unsatisfied precondition constraint (for example, init(foo id=10 - arising from un.rs:6:12: 6:22)) for expression:
foo
precondition:
init(foo id=10 - arising from un.rs:6:12: 6:22)
prestate:
!init(main! id=101 - arising from un.rs:1:0: 1:0), !init(main id=100 - arising from un.rs:1:0: 1:0), init(bar id=2 - arising from un.rs:4:8: 4:44), !init(foo id=10 - arising from un.rs:6:12: 6:22), init(b id=17 - arising from un.rs:8:8: 8:9)
un.rs:9         foo += [b];
                ^~~

The fixed code below (note line 3) compiles correctly:

fn main() {
    let bar = ["aaaaaa", "bbbbbb", "cccccc"];
    let mut foo: [str] = [];

    for b in bar { foo += [b]; }
}

[evanmcc]

OS X 10.5, intel core2duo, branch master at commit 0904f25

[catamorphism]

I agree that the error message is bad, but how would you suggest improving it? Just reduce the amount of noise?

[evanmcc]

It took me a couple of minutes of staring and poking at it before I even realized what was going on. Maybe each precondition constraint case could have a descriptive string (like, in this case, "Your local variable is uninitialized") for the compiler to throw out above the details. This might be a good balance, the plain string for the inexperienced newcomer, the detail still there for the people who need it.

Alternately, I suppose a let not followed by '=' could be a syntax error, but there might be cases where it isn't.

[catamorphism]

Yes, it's a deliberate design feature of Rust that we allow late initialization, so "let" without an '=' is not an error. (It's only an error to use a variable that isn't initialized on every incoming control path, like you saw.)

Thanks for the suggestion. I'll try to improve the error message. The info that is there right now is mainly for debugging purposes for implementors -- I never thought it was going to be useful for users, and always meant to improve the error messages, but it's just that no one has asked for that until now :-)

[evanmcc]

I suspect that I've been made lazy by writing too much Python lately, but I figured that I should log the things I did notice, since you can only go through the process fresh-eyed the once.

If it isn't a priority, I can take a look at improving the messages myself.

[catamorphism]

Feel free to try improving the messages. My main priority right now is finishing the implementation of classes, so any help with this would be much appreciated! When it comes to error messages, it's probably best to have someone who isn't the implementor do it anyway, since obviously the messages make sense to me ;-)

The main thing you'll probably want to do is distinguish between "this variable is not initialized" and "this precondition is not satisfied", which is one reason why the current message is unclear. The implementation is the same for both situations, but that doesn't mean the error message has to be. Feel free to ask for help.

[evanmcc]

How does one trigger the npred branch of the alt?

Are there many other constraints? If so, where are they defined?

I have it printing something, at this point, but I think that it's not quite the right thing, and want to fiddle with the error propagation some more.

Time is tight this weekend, but I should have something to look at early next week.

[catamorphism]

I added this as a comment in middle::tstate::auxiliary.rs, before the constraint and tsconstr types:

{{{
A constraint is either an init constraint, referring to the initialization
state of a variable (not initialized, definitely initialized, or maybe
initialized) or a predicate constraint, referring to the truth value of a
predicate on variables (definitely false, maybe true, or definitely true).

cinit and ninit represent init constraints, while cpred and npred
represent predicate constraints.

In a predicate constraint, the field (and the <def_id> field
in the npred constructor) names a user-defined function that may
be the operator in a "check" expression in the source.
}}}

Hope that's clear enough -- if not, let me know. No rush!

[catamorphism]

@evanmcc Ping? If you have code for this, I'd love to review it; if you won't have time, I'll be happy to finish it myself, but I don't want to waste any work you may have already done!

[evanmcc]

Hi Tim: I totally failed at having the time for this; I tried to
figure it out, but after 5 or six hours I realized that I'd need to
understand basically the entirety of the type system to do it cleanly.
In the end I worked on the atom problem. I should have let you know
then, sorry.

On Thu, Apr 19, 2012 at 12:34 PM, Tim Chevalier
reply@reply.github.com
wrote:

@evanmcc Ping? If you have code for this, I'd love to review it; if you won't have time, I'll be happy to finish it myself, but I don't want to waste any work you may have already done!

---

Reply to this email directly or view it on GitHub:
#2088 (comment)

[catamorphism]

@evanmcc No problem -- if you have a patch, even a partial one, feel free to submit a pull req, but otherwise I'll do it.

[evanmcc]

What I was hoping to do was two things:

1. translate the code-span information into a quoted line, so that you
   could see what was causing the error, rather than the line and
   character number

2. understand the constraints system well enough to apply a debug
   string to each class of constraint as applied, so that when you find
   that it is violated, you just throw out the debug string as a guide to
   user comprehension. I think that my mistake here was to think of
   constraints as classes of things; I couldn't get to the level of
   understanding of the implementation necessary to figure out what was
   going on. The basic thing that I did was to add a string part to the
   ninit record, but then it was difficult to trace where and why ninit
   records were being created, and there were a lot of cases where the
   debug string was something like 'get this to fail and then fix'. I
   am, overall, not sure that it's a sound approach.

Of course, tried to do #2 first, which I think led to the failure. I
needed to understand too much, and didn't want to bug you, and then I
ran out of time.

Looking forward to the commits for this, and am happy to do any
testing on it if that would help.

On Thu, Apr 19, 2012 at 12:44 PM, Tim Chevalier
reply@reply.github.com
wrote:

@evanmcc No problem -- if you have a patch, even a partial one, feel free to submit a pull req, but otherwise I'll do it.

---

Reply to this email directly or view it on GitHub:
#2088 (comment)

[brson]

punting to 0.4. initness is no longer handled by typestate, so I assume the error message has changed. is this fixed?

[nikomatsakis]

this is fixed.