Change:
assert_eq!(1, 2); } } <ins> // FIXME(Swatinem): Fix known issue that coverage code region columns need to be offset by the // doc comment line prefix (`///` or `//!`) and any additional indent (before or after the doc // comment characters). This test produces `llvm-cov show` results demonstrating the problem. // // One of the above tests now includes: `derive(Debug, PartialEq)`, producing an `llvm-cov show` // result with a distinct count for `Debug`, denoted by `^1`, but the caret points to the wrong // column. Similarly, the `if` blocks without `else` blocks show `^0`, which should point at, or // one character past, the `if` block's closing brace. In both cases, these are most likely off // by the number of characters stripped from the beginning of each doc comment line: indent // whitespace, if any, doc comment prefix (`//!` in this case) and (I assume) one space character // (?). Note, when viewing `llvm-cov show` results in `--color` mode, the column offset errors are // more pronounced, and show up in more places, with background color used to show some distinct // code regions with different coverage counts. // // NOTE: Since the doc comment line prefix may vary, one possible solution is to replace each // character stripped from the beginning of doc comment lines with a space. This will give coverage // results the correct column offsets, and I think it should compile correctly, but I don't know // what affect it might have on diagnostic messages from the compiler, and whether anyone would care // if the indentation changed. I don't know if there is a more viable solution. </ins>

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.