Make name resolution errors non-fatal

[nrc]

We can now handle name resolution errors and get past type checking (if we're a bit lucky). This is the first step towards doing code completion for partial programs (we need error recovery in the parser and early access to save-analysis).

[rust-highfive]

r? @jroesch

(rust_highfive has picked a reviewer for you, use r? to override)

[nrc]

r? @nikomatsakis

cc @rust-lang/compiler anyone can review this, I don't think it needs any special knowledge. I'd be grateful if anyone has the time.

[eddyb]

Sounds like these should be kept as typeck errors and removed from resolve.

[nikomatsakis]

This looks good to me. I agree with @eddyb that reporting an error in the case of ref i vs i is unfortunate -- it feels like a "downstream error" which would be best to suppress, though it might be a pain. Could we move that "mode" checking into typeck easily enough?

[nikomatsakis]

r+ modulo that question.

[nrc]

Seems easy enough to change to only giving a type mismatch error in that case (I hacked the change and we didn't fail any tests). However the error message is a fair bit less informative and it seems tricky to add that information to the type mismatch error, so in this case I'd be in favour of leaving the duplicate errors (or trying to suppress the type mismatch, but that is trickier and best left as a follow-up).

[nrc]

@bors: r=@nikomatsakis

[bors]

📌 Commit 18b4fe0 has been approved by @nikomatsakis

[bors]

⌛ Testing commit 18b4fe0 with merge 7aa94a2...

[bors]

💔 Test failed - auto-mac-64-nopt-t

[alexcrichton]

@bors: retry

On Mon, Dec 14, 2015 at 7:59 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-mac-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-mac-64-nopt-t/builds/7446

—
Reply to this email directly or view it on GitHub
#30320 (comment).

[bors]

⌛ Testing commit 18b4fe0 with merge bf8caf1...

[nikomatsakis]

@nrc

Seems easy enough to change to only giving a type mismatch error in that case (I hacked the change and we didn't fail any tests). However the error message is a fair bit less informative and it seems tricky to add that information to the type mismatch error, so in this case I'd be in favour of leaving the duplicate errors (or trying to suppress the type mismatch, but that is trickier and best left as a follow-up).

I was thinking of trying to suppress the type mismatch, yes. OK.