Rename occurrences of 'delay_span_bug' to 'span_delayed_bug'

since this method has been renamed in rustc.

Also remove a link to  documentation in error-guaranteed.md because it was unused

src/compiler-debugging.md

@@ -108,12 +108,12 @@ stack backtrace:
 
 If you want to get a backtrace to the point where the compiler emits an
 error message, you can pass the `-Z treat-err-as-bug=n`, which will make
-the compiler panic on the `nth` error on `delay_span_bug`. If you leave
+the compiler panic on the `nth` error on `span_delayed_bug`. If you leave
 off `=n`, the compiler will assume `1` for `n` and thus panic on the
 first error it encounters.
 
-This can also help when debugging `delay_span_bug` calls - it will make
-the first `delay_span_bug` call panic, which will give you a useful backtrace.
+This can also help when debugging `span_delayed_bug` calls - it will make
+the first `span_delayed_bug` call panic, which will give you a useful backtrace.
 
 For example:
 

src/diagnostics/error-guaranteed.md

@@ -14,7 +14,7 @@ error code path leads to a failure.
 There are some important considerations about the usage of `ErrorGuaranteed`:
 
 * It does _not_ convey information about the _kind_ of error. For example, the
-  error may be due (indirectly) to a `delay_span_bug` or other compiler error.
+  error may be due (indirectly) to a `span_delayed_bug` or other compiler error.
   Thus, you should not rely on
   `ErrorGuaranteed` when deciding whether to emit an error, or what kind of error
   to emit.
@@ -30,5 +30,4 @@ Thankfully, in most cases, it should be statically impossible to abuse
 
 [errorguar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.ErrorGuaranteed.html
 [rerrors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html
-[dsp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Handler.html#method.delay_span_bug
 [emit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html#method.emit

src/ty.md

@@ -343,18 +343,18 @@ compilation might inadvertently succeed!
 
 Sometimes there is a third case. You believe that an error has been reported, but you believe it
 would've been reported earlier in the compilation, not locally. In that case, you can invoke
-[`delay_span_bug`] This will make a note that you expect compilation to yield an error -- if however
-compilation should succeed, then it will trigger a compiler bug report.
+[`span_delayed_bug`] This will make a note that you expect compilation to yield an error -- if
+however compilation should succeed, then it will trigger a compiler bug report.
 
-[`delay_span_bug`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.delay_span_bug
+[`span_delayed_bug`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagCtxt.html#method.span_delayed_bug
 
 For added safety, it's not actually possible to produce a `TyKind::Error` value
 outside of [`rustc_middle::ty`][ty]; there is a private member of
 `TyKind::Error` that prevents it from being constructable elsewhere. Instead,
 one should use the [`TyCtxt::ty_error`][terr] or
 [`TyCtxt::ty_error_with_message`][terrmsg] methods. These methods automatically
-call `delay_span_bug` before returning an interned `Ty` of kind `Error`. If you
-were already planning to use [`delay_span_bug`], then you can just pass the
+call `span_delayed_bug` before returning an interned `Ty` of kind `Error`. If you
+were already planning to use [`span_delayed_bug`], then you can just pass the
 span and message to [`ty_error_with_message`][terrmsg] instead to avoid
 delaying a redundant span bug.