aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
diff options
context:
space:
mode:
authorMarkus Böck <markus.boeck02@gmail.com>2025-01-15 18:57:11 +0100
committerGitHub <noreply@github.com>2025-01-15 18:57:11 +0100
commitab6e63a0df9b67fb6ead026ce4ecdfd666991591 (patch)
tree2052aa751d432bd2df4f7d6c71710c757a22dc5c /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
parent1e53f9523d3d5fcb2993b4b6540f1ed8d743380b (diff)
downloadllvm-ab6e63a0df9b67fb6ead026ce4ecdfd666991591.zip
llvm-ab6e63a0df9b67fb6ead026ce4ecdfd666991591.tar.gz
llvm-ab6e63a0df9b67fb6ead026ce4ecdfd666991591.tar.bz2
[mlir] Make single value `ValueRange`s memory safer (#121996)
A very common mistake users (and yours truly) make when using `ValueRange`s is assigning a temporary `Value` to it. Example: ```cpp ValueRange values = op.getOperand(); apiThatUsesValueRange(values); ``` The issue is caused by the implicit `const Value&` constructor: As per C++ rules a const reference can be constructed from a temporary and the address of it taken. After the statement, the temporary goes out of scope and `stack-use-after-free` error occurs. This PR fixes that issue by making `ValueRange` capable of owning a single `Value` instance for that case specifically. While technically a departure from the other owner types that are non-owning, I'd argue that this behavior is more intuitive for the majority of users that usually don't need to care about the lifetime of `Value` instances. `TypeRange` has similarly been adopted to accept a single `Type` instance to implement `getTypes`.
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h')
0 files changed, 0 insertions, 0 deletions