Change:
20|       |//! 21|       |//! doctest returning a result: 22|      1|//! ``` <del> 23|      1|//! #[derive(Debug)] 24|      1|//! struct SomeError; 25|      1|//! let mut res = Err(SomeError); 26|      1|//! if res.is_ok() { 27|      0|//!   res?; 28|      1|//! } else { 29|      1|//!   res = Ok(0); 30|      1|//! } 31|       |//! // need to be explicit because rustdoc cant infer the return type 32|      1|//! Ok::<(), SomeError>(()) 33|      1|//! ``` 34|       |//! 35|       |//! doctest with custom main: 36|       |//! ``` 37|       |//! #[derive(Debug)] 38|       |//! struct SomeError; 39|       |//! 40|       |//! extern crate doctest_crate; 41|       |//! 42|      1|//! fn doctest_main() -> Result<(), SomeError> { 43|      1|//!     doctest_crate::fn_run_in_doctests(2); 44|      1|//!     Ok(()) 45|      1|//! } 46|       |//! 47|       |//! // this `main` is not shown as covered, as it clashes with all the other 48|       |//! // `main` functions that were automatically generated for doctests 49|       |//! fn main() -> Result<(), SomeError> { 50|       |//!     doctest_main() 51|       |//! } 52|       |//! ``` 53|       | 54|       |/// doctest attached to fn testing external code: 55|       |/// ``` 56|      1|/// extern crate doctest_crate; 57|      1|/// doctest_crate::fn_run_in_doctests(3); 58|      1|/// ``` 59|       |/// 60|      1|fn main() { 61|      1|    if true { 62|      1|        assert_eq!(1, 1); 63|       |    } else { 64|       |        assert_eq!(1, 2); 65|       |    } 66|      1|} </del> <ins> 23|      2|//! #[derive(Debug, PartialEq)] ^1 24|      1|//! struct SomeError { 25|      1|//!     msg: String, 26|      1|//! } 27|      1|//! let mut res = Err(SomeError { msg: String::from("a message") }); 28|      1|//! if res.is_ok() { 29|      0|//!     res?; 30|       |//! } else { 31|      1|//!     if *res.as_ref().unwrap_err() == *res.as_ref().unwrap_err() { 32|      1|//!         println!("{:?}", res); 33|      1|//!     } ^0 34|      1|//!     if *res.as_ref().unwrap_err() == *res.as_ref().unwrap_err() { 35|      1|//!         res = Ok(1); 36|      1|//!     } ^0 37|      1|//!     res = Ok(0); 38|       |//! } 39|       |//! // need to be explicit because rustdoc cant infer the return type 40|      1|//! Ok::<(), SomeError>(()) 41|      1|//! ``` 42|       |//! 43|       |//! doctest with custom main: 44|       |//! ``` 45|      1|//! fn some_func() { 46|      1|//!     println!("called some_func()"); 47|      1|//! } 48|       |//! 49|       |//! #[derive(Debug)] 50|       |//! struct SomeError; 51|       |//! 52|       |//! extern crate doctest_crate; 53|       |//! 54|      1|//! fn doctest_main() -> Result<(), SomeError> { 55|      1|//!     some_func(); 56|      1|//!     doctest_crate::fn_run_in_doctests(2); 57|      1|//!     Ok(()) 58|      1|//! } 59|       |//! 60|       |//! // this `main` is not shown as covered, as it clashes with all the other 61|       |//! // `main` functions that were automatically generated for doctests 62|       |//! fn main() -> Result<(), SomeError> { 63|       |//!     doctest_main() 64|       |//! } 65|       |//! ``` 66|       | 67|       |/// doctest attached to fn testing external code: 68|       |/// ``` 69|      1|/// extern crate doctest_crate; 70|      1|/// doctest_crate::fn_run_in_doctests(3); 71|      1|/// ``` 72|       |/// 73|      1|fn main() { 74|      1|    if true { 75|      1|        assert_eq!(1, 1); 76|       |    } else { 77|       |        assert_eq!(1, 2); 78|       |    } 79|      1|} 80|       | 81|       |// FIXME(Swatinem): Fix known issue that coverage code region columns need to be offset by the 82|       |// doc comment line prefix (`///` or `//!`) and any additional indent (before or after the doc 83|       |// comment characters). This test produces `llvm-cov show` results demonstrating the problem. 84|       |// 85|       |// One of the above tests now includes: `derive(Debug, PartialEq)`, producing an `llvm-cov show` 86|       |// result with a distinct count for `Debug`, denoted by `^1`, but the caret points to the wrong 87|       |// column. Similarly, the `if` blocks without `else` blocks show `^0`, which should point at, or 88|       |// one character past, the `if` block's closing brace. In both cases, these are most likely off 89|       |// by the number of characters stripped from the beginning of each doc comment line: indent 90|       |// whitespace, if any, doc comment prefix (`//!` in this case) and (I assume) one space character 91|       |// (?). Note, when viewing `llvm-cov show` results in `--color` mode, the column offset errors are 92|       |// more pronounced, and show up in more places, with background color used to show some distinct 93|       |// code regions with different coverage counts. 94|       |// 95|       |// NOTE: Since the doc comment line prefix may vary, one possible solution is to replace each 96|       |// character stripped from the beginning of doc comment lines with a space. This will give coverage 97|       |// results the correct column offsets, and I think it should compile correctly, but I don't know 98|       |// what affect it might have on diagnostic messages from the compiler, and whether anyone would care 99|       |// if the indentation changed. I don't know if there is a more viable solution. </ins> ../coverage/lib/doctest_crate.rs: 1|       |/// A function run only from within doctests

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduced from another code sample: `
- Thanks for the ICE report, and the reduced code sample! - The reduced sample produces a couple of MIR that make it to PreCodegen, one of which is: And you can see that there are two different counters with ID "1". Most likely, is merging one MIR into another, or something like that, combining counters from different "functions". The output (shown above in this issue) shows the new warning that I recently : Until seeing this post, I wasn't aware that might also break coverage altogether (and cause an ICE). I don't believe we should be trying to support this option combination. I can replace the warning with an error (and update the message to say they are incompatible, or something like that). For this type of problem, I think the failed assertion is still valid (the MIR is invalid), and it is better to fail on the option combination, rather than try to gracefully recover somehow. WDYT?
Yeah it looks like was inlined which is where one of the counters came from. Is there anyway we could the MIR inliner to support handling coverage statements? For example, could we renumber the counter ids so they are unique again? If that is infeasible, we should probably just have the inline pass disable itself if code coverage is enabled. Yeah, I agree! It seems like it will be easier for us to diagnose the ICE than to try to figure out why coverage data is missing or behaving incorrectly.
Update: The solution implemented by is different from what we initially agreed on. More detail can be found in the PR discussion, but to be more future-proof, we didn't want to disable everything at the same that enables inlining.

That means 2 is allowed with , but the pass is disabled, regardless of the level. If inlining is ever moved to 1 (the default), inlining will still be disabled. If a non-default is specified, a warning is generated to inform the developer that inlining is not enabled by that change. (The warning will not be displayed if inlining is moved to the default (1) level in the future.) As noted in the PR discussion, I don't believe it's worth trying to hack around the LLVM instrprof expectation that each function actually be an LLVM function. Source-based coverage is not meant for production code, so disabling inlining seems like a much better way to address the problem; and now that it only affects the inlining part, it still allows for other optimizations, which is an improvement (in addition to preventing the ICE). Lastly, I would stress that there may (or may not) still be other compiler flags and/or other optimizations that are found to be incompatible with LLVM Instrprof coverage, as implemented. But the test in this issue does now work, with 2 enabled.