[Mlir-commits] [mlir] [mlir][dataflow] Fix for integer range analysis propagation bug (PR #93199)

[Mehdi Amini]

================
@@ -27,6 +27,9 @@ namespace intrange {
 using InferRangeFn =
     function_ref<ConstantIntRanges(ArrayRef<ConstantIntRanges>)>;
 
+using OptionalRangeFn =
+    std::function<OptionalIntRanges(ArrayRef<OptionalIntRanges>)>;
----------------
joker-eph wrote:

`function_ref` is unsafe as a return value in general, but it should always be safe when transiently used as function arguments. 
It's slightly more murky when a reference is kept, because the caller must keep the called object alive (but that's just "business as usual": anytime you pass a pointer/reference to a method that keeps  a copy of it you have this situation).

It can be tricky in situations like this:

```
std::function<void()> bar();
std::function<void()> foo(function_ref<void()> callable) {
  // The returned std::function copies the callable function_ref
  return [=]() { 
     callable();
  };
```

If we write:
```
std::function<void()> bar_result = bar();
std::function<void()> foo_result = foo(bar_result);
```

Then it's just fine (but careful: foo_result has a reference to `bar_result`, now bar_result must outlive uses of `foo_result`).
So it is buggy to write:

```
std::function<void()> foo_result = foo(bar());
```

Because now `foo_result` has a reference to a dangling object (the result of `bar()`).



https://github.com/llvm/llvm-project/pull/93199