rustc: Fix cstack lint for default methods. Closes #8753

[brson]

No description provided.

[alexcrichton]

Could this actually be changed to a compile-fail test to ensure that it still fails in the situation that fixed_stack_segment is omitted on a default method?

[alexcrichton]

As in have both the positive and negative cases, ensuring that only the negative case has an error

[brson]

@alexcrichton yes. done

[pnkfelix]

niko and I discussed the error here. This is probably a check-fast specific problem (which I am not sure I checked on my end before now, though I have a least duplicated the problem locally at this point), and it is not clear whether it is exposing an underlying resolve bug, or if the error is expected behavior and the test needs revision. Will poke a bit more.

[pnkfelix]

I can replicate the problem via make check-fast on non-Windows hosts

For better or for worse: when I change the file like so, the problem goes away:

Update: (there are two ways to solve this, and this top version follows the pattern set by existing tests more properly):

diff --git a/src/test/run-pass/lint-cstack.rs b/src/test/run-pass/lint-cstack.rs
index 8e5ab54..b9e61b4 100644
--- a/src/test/run-pass/lint-cstack.rs
+++ b/src/test/run-pass/lint-cstack.rs
@@ -8,8 +8,10 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.

+use std::libc;
+
 extern {
-    fn rust_get_test_int() -> std::libc::intptr_t;
+    fn rust_get_test_int() -> libc::intptr_t;
 }

 trait A {

(Original but not-as-good patch follows):

diff --git a/src/test/run-pass/lint-cstack.rs b/src/test/run-pass/lint-cstack.rs
index 8e5ab54..c665342 100644
--- a/src/test/run-pass/lint-cstack.rs
+++ b/src/test/run-pass/lint-cstack.rs
@@ -9,7 +9,7 @@
 // except according to those terms.

 extern {
-    fn rust_get_test_int() -> std::libc::intptr_t;
+    fn rust_get_test_int() -> ::std::libc::intptr_t;
 }

 trait A {

This is presumably because lint-cstack assumes that it will only be used as a module from the system top-level, but the check-fast target pulls that file in as a submodule within run_pass_stage2.

Niko had claimed to me earlier that the run_pass_stage2 module would also pull in the std module at the same level (which made me think that the code as written should be fine), but I do not see a sign of such a use of mod std being done in run_pass_stage2

So it seems like the potential fixes here are:

1. Change lint-cstack to use absolute reference of intptr_t
2. Change run_pass_stage2 to use std (so that all the modules it uses can also reference std relatively, right?)
3. Change resolve in some way to handle this special case (but why would we do that if at least one of the above two solutions is acceptable?)

[pnkfelix]

@brson: can you update your Pull Request with one of the diffs from my previous comment so that we can land it?

[brson]

@pnkfelix yes done