diff options
| author | Markus Böck <markus.boeck02@gmail.com> | 2025-01-15 18:57:11 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-01-15 18:57:11 +0100 |
| commit | ab6e63a0df9b67fb6ead026ce4ecdfd666991591 (patch) | |
| tree | 2052aa751d432bd2df4f7d6c71710c757a22dc5c /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h | |
| parent | 1e53f9523d3d5fcb2993b4b6540f1ed8d743380b (diff) | |
| download | llvm-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
