Cargo test randomly ignores all ```no_run and fails

help
1

I have some docs with pre-formatted text and just examples of code that I don't want to run as doctests. I annotated all them with no_run after ```, as the docs suggest. And suddenly cargo started to run them sometimes, and complain of all the possible deadly sins: wrong syntax, global variables, etc.

Chances of this happening is like 1 of 2.

To be sure, I dropped the entire target directory, but the effect is still the same.

What can be the reason for this?

Reasons I can think of:

  • doc comments with Cyrillic
  • saving files in VSCode, and then running the tests in a separate bash shell (but after I leave VSCode, and run cargo t in the shell multiple times, the randomness is still there)

Example of doc comments:

/// Граф с 5 перекрёстками, все дороги двусторонние.
/// ```no_run
///        0
///   +---0,3----o---2,10----+
///   |          |           |
///   |          |1,6        |
///   |          |           |
/// 1 o---4,7----o2---8,11---o 3
///   |          |           |
///   |          |9,14       |
///   |          |           |
///   +---5,13---o---12,15---+
///              4
/// ```
pub fn four_squares_graph2() -> Graph {

(the triple backquote here is for convenience: when I hover the function name in tests, I see its doc formatted, and can view the ascii diagram)

Edit: I found out that if there's text at 1 space from ///, and then there's blank doc line, and then text intented with 5 spaces, the latter is treated as preformatted text, and ever highlighted in VSCode, but not seen as doctest by cargo.

2

The no_run attribute will compile your code but not run it.

as per the doc tests docs.

tag it with text or ignore if what's in there is not Rust code.

2 Likes
3

no_run is for rust code only, it still compiles the code, but does not run it.

for non-rust blocks (be it code in other languages, or non-code texts), use the ignore attribute.

2 Likes
4

Thank you both! This makes sense. I made these code blocks when my real tests were broken, which shadowed the compilation issue.

Looks like, the randomness comes from one of the tests failing or succeeding, depending on how objects are ordered in a hashmap or something like this.