[all-commits] [llvm/llvm-project] ab6e63: [mlir] Make single value `ValueRange`s memory safe...

[Markus Böck via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ab6e63a0df9b67fb6ead026ce4ecdfd666991591
      https://github.com/llvm/llvm-project/commit/ab6e63a0df9b67fb6ead026ce4ecdfd666991591
  Author: Markus Böck <markus.boeck02 at gmail.com>
  Date:   2025-01-15 (Wed, 15 Jan 2025)

  Changed paths:
    M mlir/include/mlir/IR/TypeRange.h
    M mlir/include/mlir/IR/ValueRange.h
    M mlir/lib/IR/OperationSupport.cpp
    M mlir/lib/IR/TypeRange.cpp
    M mlir/unittests/IR/OperationSupportTest.cpp

  Log Message:
  -----------
  [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`.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications