documentation followup for "invert linetable representation (#52415)" (…

…#53781)

- fix up added documents: eb05b4f
- ~~set up a specific type to capture the 3-set data of `codelocs`:
6afde4b~~ (moved to a separate PR)

doc/src/devdocs/ast.md

@@ -696,14 +696,10 @@ A (usually temporary) container for holding lowered source code.
     Statement-level 32 bits flags for each expression in the function.
     See the definition of `jl_code_info_t` in julia.h for more details.
 
-  * `linetable`
-
-    An array of source location objects
-
-  * `codelocs`
+  * `debuginfo`
 
-    An array of integer indices into the `linetable`, giving the location associated
-    with each statement.
+    An object to retrieve source information for each statements, see
+    [How to interpret line numbers in a `CodeInfo` object](@ref).
 
 Optional Fields:
 
@@ -769,7 +765,7 @@ Boolean properties:
     See the documentation of `Base.@assume_effects` for more details.
 
 
-How to interpret line numbers in a `CodeInfo` object:
+#### How to interpret line numbers in a `CodeInfo` object
 
 There are 2 common forms for this data: one used internally that compresses the data somewhat and one used in the compiler.
 They contain the same basic info, but the compiler version is all mutable while the version used internally is not.
@@ -780,7 +776,7 @@ Many consumers may be able to call `Base.IRShow.buildLineInfoNode`,
 
 The definitions of each of these are:
 
-```
+```julia
 struct Core.DebugInfo
     @noinline
     def::Union{Method,MethodInstance,Symbol}
@@ -801,11 +797,11 @@ end
 ```
 
 
-  * `def` : where this DebugInfo was defined (the Method, MethodInstance, or file scope, for example)
+  * `def` : where this `DebugInfo` was defined (the `Method`, `MethodInstance`, or `Symbol` of file scope, for example)
 
   * `linetable`
 
-    Another debuginfo that this was derived from, which contains the actual line numbers,
+    Another `DebugInfo` that this was derived from, which contains the actual line numbers,
     such that this DebugInfo contains only the indexes into it. This avoids making copies,
     as well as makes it possible to track how each individual statement transformed from
     source to optimized, not just the separate line numbers. If `def` is not a Symbol, then
@@ -820,27 +816,26 @@ end
   * `firstline` (when uncompressed to DebugInfoStream)
 
     The line number associated with the `begin` statement (or other keyword such as
-    `function` or `quote`) that delinated where this code definition "starts".
+    `function` or `quote`) that delineates where this code definition "starts".
 
-  * `codelocs` (when uncompressed to DebugInfoStream)
+  * `codelocs` (when uncompressed to `DebugInfoStream`)
 
     A vector of indices, with 3 values for each statement in the IR plus one for the
     starting point of the block, that describe the stacktrace from that point:
      1. the integer index into the `linetable.codelocs` field, giving the
         original location associated with each statement (including its syntactic edges),
         or zero indicating no change to the line number from the previously
-        executed statement (which is not necessarily syntactic or lexical prior).
-       or
-       the line number itself if the `linetable` field is `nothing`
-     2. the integer index into edges, giving the DebugInfo inlined there (or zero if there
-        are no edges).
-     3. (if entry 2 is non-zero) the integer index into edges[].codelocs, to interpret
-        recursively for each function in the inlining stack, or zero indicating to use
-        `edges[].firstline` as the line number.
-
-   Special codes include:
-     - (zero, zero, *) : no change to the line number or edges from the previous statement
+        executed statement (which is not necessarily syntactic or lexical prior),
+        or the line number itself if the `linetable` field is `nothing`.
+     2. the integer index into `edges`, giving the `DebugInfo` inlined there,
+        or zero if there are no edges.
+     3. (if entry 2 is non-zero) the integer index into `edges[].codelocs`,
+        to interpret recursively for each function in the inlining stack,
+        or zero indicating to use `edges[].firstline` as the line number.
+
+    Special codes include:
+     - `(zero, zero, *) `: no change to the line number or edges from the previous statement
        (you may choose to interpret this either syntactically or lexically). The inlining
        depth also might have changed, though most callers should ignore that.
-     - (zero, non-zero, *) : no line number, just edges (usually because of macro-expansion into
-       top-level code)
+     - `(zero, non-zero, *)` : no line number, just edges (usually because of
+       macro-expansion into top-level code).