Change:
<ins> error: `[i]` cannot be resolved, ignoring it... --> $DIR/intra-link-span-ice-55723.rs:21:10 | LL | /// （arr[i]） |           ^ cannot be resolved, ignoring | note: lint level defined here --> $DIR/intra-link-span-ice-55723.rs:13:9 | LL | #![deny(intra_doc_link_resolution_failure)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = help: to escape `[` and `]` characters, just add '/' before them like `/[` or `/]` </ins>

Discussion:
ICE happened when run :
Works fine for me. Anything else besides the given information?
I can't seem to reproduce that ICE with that nightly. Are there any other details about your project that you can tell us about? The panic itself seems to originate in libsyntax, in a function about tracking multi-byte characters in source files:
try this:
Still working fine.
you can try this github reps:
I think the bug is caused by that looked for the wrong location in method.
Ah nice, thanks!
Log with backtrace from a local rustdoc build: <details<summaryFull backtrace</summary</detailsBased on that backtrace, it looks like it's a problem with the reporting of intra-doc link resolution errors, and the span we're calculating from the link reference. These spans are constructed from byte ranges we calculate in , when scanning markdown for link references: Oddly enough, vim seems to re-encode those parentheses in a way that makes the problem go away, so writing this into a test will be exceedingly difficult. This may explain why i couldn't reproduce the issue, because when i copy/pasted the sample into vim, it no longer had the encoding problem. An immediate work-around for you is to backslash-escape the square brackets on that line, to stop the markdown parser from thinking it's a link.
Oh hang on, i think i've found what's going on. Vim only led me astray because of a plugin i had that caused me to change the test and "solve" the issue. If you look closely at the reproduction... The "blank" line in the middle is actually hiding something important: trailing whitespace. This causes some code later on to fail, that tries to convert the byte range given in the sample i linked into a byte range representative of the code: That is likely the culprit. (I'm waiting on a build right now, but i'll test this hunch once it's available.) I bet that calculation is incorrectly trimming off that trailing whitespace, which is creating a offset that is causing the index of the span to be incorrectly offset from its actual position... straight into the middle of a multibyte codepoint. Change that to and the issue will probably disappear. Another workaround (which will make the error properly appear) is to trim any trailing whitespace in your file, which will cause this calculation use the correct range for the text.

I've opened to fix this issue. There are still problems with this calculation, but it should fix your situation, at least.
Ask a question: I don't understand why not write directly like this:
ok, I see, In order to calculate the preceding whitespaces. But rustfmt can delete the whitespace.
Right, the extra calculation is meant to deal with the indentation level, since we're dealing with the plain-text source code there. Also, if is zero (i haven't read that code in a while, so i'm not sure if it's supposed to be) then that can also lead to an incorrect calculation with your version. I'm not sure i understand the reference? Rustdoc can't assume the presence of other tools, and we can't force everyone to start using rustfmt to be able to generate docs.
Ok, I see. thanks for your reply.