Fix bad handling of macros if there is already a main function

Author: GuillaumeGomez

src/librustdoc/doctest/make.rs

@@ -424,7 +424,10 @@ fn parse_source(source: &str, crate_name: &Option<&str>) -> Result<ParseSourceIn
                     // We assume that the macro calls will expand to item(s) even though they could
                     // expand to statements and expressions. And the simple fact that we're trying
                     // to retrieve a `main` function inside it is a terrible idea.
-                    StmtKind::MacCall(ref mac_call) if !info.has_main_fn => {
+                    StmtKind::MacCall(ref mac_call) => {
+                        if info.has_main_fn {
+                            continue;
+                        }
                         let mut iter = mac_call.mac.args.tokens.iter();
 
                         while let Some(token) = iter.next() {

tests/rustdoc-ui/doctest/auxiliary/macro-after-main.rs

@@ -0,0 +1 @@
+use std::string::String;

tests/rustdoc-ui/doctest/macro-after-main.rs

@@ -0,0 +1,16 @@
+// This test checks a corner case where the macro calls used to be skipped,
+// making them considered as statement, and therefore some cases where
+// `include!` macro was then put into a function body, making the doctest
+// compilation fail.
+
+//@ compile-flags:--test
+//@ normalize-stdout: "tests/rustdoc-ui/doctest" -> "$$DIR"
+//@ normalize-stdout: "finished in \d+\.\d+s" -> "finished in $$TIME"
+//@ check-pass
+
+//! ```
+//! include!("./auxiliary/macro-after-main.rs");
+//!
+//! fn main() {}
+//! eprintln!();
+//! ```

tests/rustdoc-ui/doctest/macro-after-main.stdout

@@ -0,0 +1,6 @@
+
+running 1 test
+test $DIR/macro-after-main.rs - (line 11) ... ok
+
+test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME
+