no_run doctests no longer verify lints

[alexcrichton]

For code like this:

#![doc(test(attr(deny(warnings))))]

/// ```no_run
/// let a = 3;
/// ```
pub fn foo() {}

The stable/beta rustdoc will generate an error, while the nightly rustdoc will pass silently. This block looks suspicious perhaps?

r? cc @nrc

[alexcrichton]

er, that r? was meant to be a cc

[alexcrichton]

Tagging as a regression and nominating

[crumblingstatue]

The borrow checker also does not seem to operate on no_run tests.

//! ```no_run
//! fn main() {
//! let mut s = "hello".to_owned();
//! let ref1 = &mut s;
//! let ref2 = &mut s;
//! }
//! ```

Will pass the Doc-tests.

[steveklabnik]

@crumblingstatue 's error does not happen on

rustc 1.9.0-nightly  (388ccda45 2016-03-07)

so it must have happened recently.

[crumblingstatue]

@steveklabnik
The Doc-Test also passes on rustc 1.8.0-beta.1 (facbfdd71 2016-03-02). It fails on stable, which is the correct behavior.
How are you testing it?
I use rustdoc --test foo.rs

[steveklabnik]

I meant that the test fails, sorry. I cannot reproduce the bug.

On Mar 10, 2016, 15:35 +0100, Mika Attilanotifications@github.com, wrote:

@steveklabnik(https://github.com/steveklabnik)
The Doc-Test also passes onrustc 1.8.0-beta.1 (facbfdd 2016-03-02). It fails on stable, which is the correct behavior.
How are you testing it?
I userustdoc --test foo.rs

—
Reply to this email directly orview it on GitHub(#31576 (comment)).

[crumblingstatue]

Just to show a real life case, and the fact that this is not just an anomaly on my local system, here is a travis build of a project that passes on both beta and nightly, but fails (properly) on stable.

https://travis-ci.org/jeremyletang/rust-sfml/builds/115021280

[nikomatsakis]

@nrc, any thoughts?

[nikomatsakis]

tagging with T-compiler just so we can review in compiler mtg, even though it's sort of more tools.

[nikomatsakis]

triage: P-high

[alexcrichton]

Bisection-via-nightly turns up 2016-02-01 was the last good and 2016-02-02 is the first bad. This points to some commit between 094c5b0 and b94cd7a, of which the most suspect is #31250.

This line looks quite suspect, returning that there are 0 errors when result may otherwise indicate that errors would have happened.

Ok so after writing all that up I tested it out and I'll just make a PR soon.