llvm-project

fd65b3ef - [GlobalISel] Fix UMR in `SwiftErrorValueTracking` (#190273)

[GlobalISel] Fix UMR in `SwiftErrorValueTracking` (#190273) Fix issue reported on https://github.com/llvm/llvm-project/pull/188296#issuecomment-4179103756 `SwiftErrorValueTracking` holds per-function state used by `IRTranslator`. On targets where `TargetLowering::supportSwiftError()` is false, (e.g. wasm) `SwiftErrorValueTracking::setFunction()` exits early. Historically, that early return happened before clearing per-function containers, and pointer members (including `SwiftErrorArg`) had no in-class initialization. The bad case is a function with a swifterror argument on such a target: `IRTranslator` uses `SwiftError.getFunctionArg()` without checking `supportSwiftError()` and this could read an uninitialized `SwiftErrorArg` value. (SelectionDAG gates the `getFunctionArg` usages behind `supportSwiftError()`, so it's specific to GlobalISel) 29391328ab66 added [a first test case](llvm/test/CodeGen/WebAssembly/GlobalISel/irtranslator/args-swiftcc.ll) that satisfies: - the target is `supportSwiftError` = false - use swiftcc - use GlobalISel and it made the issue observable with sanitizer builds. This commit fixes the per-function container reinitialization and defensively add explicit pointer member initializations.