[AsmParser][MCContext] Solving the problem of printing symbol positions at the end of the file

I start trying to solve this problem in August. I've tried several different approaches along the way.

Here's my pull request below:

**#214396:** The approach taken in the first attempt was to use `std::get` to retrieve the relative parameters, drawing inspiration from the method used for relative parameters in the `std::tuple` for-loop shown below. Assistant: Gemini 3.5 flash

**#214654:** Use the `LocalSymbolLoc.find()` and `LocalSymbolLoc.end()` methods to resolve the entry, and use `LocalSymbolLocs.try_emplace()` to store it in the previously created `FirstTokenLoc` hash table.

```cpp
// FIXME: We would really like to refer back to where the symbol was
// first referenced for a source location. We need to add something
// to track that. Currently, we just point to the end of the file.
printError(getTok().getLoc(), "assembler local symbol '" + Sym->getName() + "' not defined");
```

Later, I started using bazel to compile an llvm-mc with debug symbols, and then used gdb to debug it, setting two breakpoints with `AsmParser::Run` and `AsmParser::parsePrimaryExpr` functions. Then I added the parameter `-triple=x86_64-apple-macos` to specify the platform during runtime. The following information was obtained by printing the call stack:

```
#0 (anonymous namespace)::AsmParser::parsePrimaryExpr (this=0x555559b56d80, Res=@0x7fffffffc118: 0x0, EndLoc=..., TypeInfo=0x0)
at external/+_repo_rules+llvm-project/llvm/lib/MC/MCParser/AsmParser.cpp:1122
#1 0x000055555866ac53 in (anonymous namespace)::X86AsmParser::parsePrimaryExpr (this=0x555559b5ae00, Res=@0x7fffffffc118: 0x0, EndLoc=...)
at external/+_repo_rules+llvm-project/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3262
#2 0x00005555593c1922 in (anonymous namespace)::AsmParser::parseExpression (this=0x555559b56d80, Res=@0x7fffffffc118: 0x0, EndLoc=...)
at external/+_repo_rules+llvm-project/llvm/lib/MC/MCParser/AsmParser.cpp:1451
#3 0x0000555558667c3e in (anonymous namespace)::X86AsmParser::parseATTOperand (this=0x555559b5ae00, Operands=...)
at external/+_repo_rules+llvm-project/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:2836
#4 0x000055555865fc5c in (anonymous namespace)::X86AsmParser::parseOperand (this=0x555559b5ae00, Operands=..., Name=...)
at external/+_repo_rules+llvm-project/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:1783
#5 0x000055555866e133 in (anonymous namespace)::X86AsmParser::parseInstruction (this=0x555559b5ae00, Info=..., Name=..., NameLoc=..., Operands=...)
at external/+_repo_rules+llvm-project/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:3634
#6 0x00005555583d29ac in llvm::MCTargetAsmParser::parseInstruction (this=0x555559b5ae00, Info=..., Name=..., Token=..., Operands=...)
at external/+_repo_rules+llvm-project/llvm/include/llvm/MC/MCParser/MCTargetAsmParser.h:435
```

Later, using the automatic navigation function of the integrated development environment, I navigated from the `Sym->isTemporary()` function to the `MCSymbol.h` file, and then from the variable returned by this function back to the `MCSymbol.h` file. I discovered that the `isTemporary` variable is a bit field declaration.

Later, while reading the source code, I found a section of it in the public part of the `AsmParser` class, around lines 198-204. There's a function called `AsmParser` that calls the `MCContext` class. Near `AsmParser`, around lines 250-260, there's a function called `parsePeimaryExpr`, which contains constants from the `MCExpr` class. Jumping to this function leads to the branch logic of `AsmToken::Identifier` that processes the identifier (e.g., `Ltmp0`, `main`). Then I went into the `MCContext.h` header file and found the functions `setSymbolLoc` and `getSymbolLoc`. Incidentally, I also introduced a mechanism to check if the identifier exists in the `MCExpr.cpp` module.

**#219719:** This is a rough code implementation based on my above ideas， it still needs improvement.

Start with llvm/lib/MC/MCParser/AsmParser.cpp, especially AsmParser::parsePrimaryExpr, and review MCContext.h's setSymbolLoc and getSymbolLoc. Read the referenced pull requests #214396 and #214654, then inspect issue #219719 before choosing an approach. Done means undefined local-symbol diagnostics report the relevant symbol position instead of the end of the file, with tests covering the behavior.

Written by the indexing model from the issue text.