[DebugInfo] Fix wrong scope being used in AllocBoxToStack

(cherry picked from commit f6232a9)

Author: Snowy1803

docs/DebuggingTheCompiler.md

@@ -260,7 +260,7 @@ If one builds swift using ninja and wants to dump the SIL of the
 stdlib using some of the SIL dumping options from the previous
 section, one can use the following one-liner:
 
-    ninja -t commands | grep swiftc | grep Swift.o | grep " -c "
+    ninja -t commands | grep swiftc | grep 'Swift\.o'
 
 This should give one a single command line that one can use for
 Swift.o, perfect for applying the previous sections options to.

docs/HowToUpdateDebugInfo.md

@@ -16,6 +16,11 @@ merge drop and copy locations, since all the same considerations apply. Helpers
 like `SILBuilderWithScope` make it easy to copy source locations when expanding
 SIL instructions.
 
+> [!Warning]
+> Don't use `SILBuilderWithScope` when replacing a single instruction of type
+> `AllocStackInst` or `DebugValueInst`. These meta instructions are skipped,
+> so the wrong scope will be inferred.
+
 ## Variables
 
 Each `debug_value` (and variable-carrying instruction) defines an update point
@@ -254,16 +259,34 @@ debug_value %1 : $Int, var, name "pair", type $Pair, expr op_fragment:#Pair.a //
 ```
 
 ## Rules of thumb
-- Optimization passes may never drop a variable entirely. If a variable is
-  entirely optimized away, an `undef` debug value should still be kept. The only
-  exception is an unreachable function or scope, which is entirely removed.
-- A `debug_value` must always describe a correct value for that source variable
-  at that source location. If a value is only correct on some paths through that
-  instruction, it must be replaced with `undef`. Debug info never speculates.
-- When a SIL instruction is deleted, call salvageDebugInfo(). It will try to
-  capture the effect of the deleted instruction in a debug expression, so the
-  location can be preserved. You can also use an `InstructionDeleter` which will
-  automatically call `salvageDebugInfo`.
+
+### Correctness
+A `debug_value` must always describe a correct value for that source variable
+at that source location. If a value is only correct on some paths through that
+instruction, it must be replaced with `undef`. Debug info never speculates.
+
+### Don't drop debug info
+
+Optimization passes may never drop a variable entirely. If a variable is
+entirely optimized away, an `undef` debug value should still be kept. The only
+exception is when the variable is in an unreachable function or scope, where it
+can be removed with the rest of the instructions.
+
+### Instruction Deletion
+
+When a SIL instruction is deleted, call `salvageDebugInfo`. It will try to
+capture the effect of the deleted instruction in a debug expression, so the
+location can be preserved.
+
+Alternatively, you can use an `InstructionDeleter`, which will automatically
+call `salvageDebugInfo`.
+
+If the debug info cannot be salvaged by `salvageDebugInfo`, and the pass has a
+special knowledge of the value, the pass can directly replace the debug value
+with the known value.
+
+If an instruction is being replaced by another, use `replaceAllUsesWith`. It
+will also update debug values to use the new instruction.
 
 > [!Tip]
 > To detect when a pass drops a variable, you can use the

lib/SIL/IR/SILInstruction.cpp

@@ -1475,9 +1475,8 @@ bool SILInstruction::mayTrap() const {
 }
 
 bool SILInstruction::isMetaInstruction() const {
-  // Every instruction that implements getVarInfo() should be in this list.
+  // Every instruction that doesn't generate code should be in this list.
   switch (getKind()) {
-  case SILInstructionKind::AllocBoxInst:
   case SILInstructionKind::AllocStackInst:
   case SILInstructionKind::DebugValueInst:
     return true;