Updated metadata::creader::resolve_crate_deps to use the correct span

[cmacknz]

Addresses FIXME described in issue #2404

[alexcrichton]

I'm not sure that this solves the bug at hand. The problem here is that you're loading the dependency of an explicitly mentioned crate, but you then fail to load the dependency. As implemented, you'll get an error message that looks like:

extern mod extra; //~ ERROR: could not find crate for `std`

I agree that the span is probably pointing at the right location right now, but I think that the error message needs to be updated to fix the bug in question.

Additionally, this change should be accompanied with a compile-fail test that ensures that the message is printed at the right location.

[cmacknz]

@alexcrichton Since #2404 is pretty light on details do you have any suggestions as to how to set up a test case to reproduce the error I'm trying to fix? My understanding of how crates are resolved/loaded is a work in progress.

[alexcrichton]

Try these steps:

1. Compile crate A.
2. Compile crate B, which depends on A.
3. Remove crate A.
4. Compile crate C which depends on B.

The 4th step should have a message saying that A couldn't be found which is a dependency of B with a span pointing at extern mod B;

[cmacknz]

Thanks. How should I modify the error message?

Before correcting the FIXME I get:

crateC.rs:1:1: 1:1 error: can't find crate for `crateA`
crateC.rs:1 extern mod crateB;
            ^

After:

crateC.rs:1:1: 1:19 error: can't find crate for `crateA`
crateC.rs:1 extern mod crateB;
            ^~~~~~~~~~~~~~~~~~

[alexcrichton]

Something like:

crateC.rs:1:1: 1:19 error: can't find crate for `crateA`, which `crateB` depends on
crateC.rs:1 extern mod crateB;
            ^~~~~~~~~~~~~~~~~~

[cmacknz]

Error message is now as follows:

crateC.rs:1:1: 1:19 error: can't find crate for `crateA` which `extern mod crateB` depends on
crateC.rs:1 extern mod crateB;
            ^~~~~~~~~~~~~~~~~~

[alexcrichton]

This seems to look quite similar to the original version, perhaps a forgotten force-push?

[cmacknz]

Sorry, should have said "Error message will be as follows".

I'm still trying to figure out the best way to write a test for this. That I need to compile two crates and then delete one of them requires the Makefile functionality from tests/run-make. However, that isn't compatible with the requirement that this is a compile-fail test.

Have any suggestions on this?

[alexcrichton]

Oh sorry, I'd change extern mod crateB to just crateB, but otherwise that looks good to me!

As for testing, the usual compiletest infrastructure may not be good enough here, but you should be able to write a run-make test to do the fancy things. Sadly it's not as accurate with checking where the error is emitted, but you could always grep for line numbers which would just be a little fragile if it changed (but not too bad).

[cmacknz]

Changes are up now.

[alexcrichton]

Sadly ERROR directives are not parsed during the run-make tests. I would recommend storing the output of rustc and then invoking grep to make sure that it printed a vaguely correct message.

[cmacknz]

Updated to be syntax agnostic.

[alexcrichton]

You shouldn't have to clone() here.

[alexcrichton]

Looks good to me, thanks!

Could you squash these commits together and make sure that Closes #2404 shows up in the commit message as well?

[cmacknz]

Done.