rustdoc: Since 1.87 we permit shebangs in doctests that have a `main` fn

[fmease]

Note

This topic was already extensively discussed in #t-rustdoc/meetings > 2025-09-08 @ 💬. Verdict is still unclear, namely whether to simply accept it as an accidental feature (would need FCP after the fact with motivation) or revert (wouldn't need an FCP, might need a crater run).

Since PR #138104 (stabilized in 1.87), we accidentally permit rustdoc file.rs --test where file.rs:

//! ```
//! #!XYZ XYZ XYZ XYZ XYZ
//! fn main() {}
//! ```

[fmease]

The following is only semi-related but I don't want to open a new issue at this time ^^'.

For context, apart from shebang we also permit frontmatter since that PR – provided the feature was enabled. Since that's still unstable it's not a stable-to-stable regression and thus I didn't mention it in the issue description.

Now, while frontmatter in doctests works under --test (if #![feature(frontmatter)]), we can actually emit the lint rustdoc::invalid_rust_codeblocks "due to them" under normal execution. That's because the lint impl uses source_str_to_stream which presently passes StripTokens::Shebang (not StripTokens::ShebangAndFrontmatter) to source_file_to_stream. We should make the lint & doctest building agree with each other whether that's stripping frontmatter & shebang or not. Reproducer:

//! ```
//! ---
//! §
//! ---
//! #![feature(frontmatter)]
//! fn main() {}
//! ```

[fmease]

Okay, so during our "static analysis pass" (trying to find a main fn, crate attrs, extern crate items) the parser does fail to parse the input (& we intentionally don't emit any syntax errors), so we generate a dummy doctest that's flagged as invalid. Here is the kicker: Since we don't rewrap invalid doctests in a dummy fn before we pass it to rustc, rustc actually gets to parse the doctest as user written meaning shebang and frontmatter gets stripped successfully.

I've yet to fully confirm what we did before but ultimately we did rewrap these two snippets leading to a compile fail in the end.