diff options
| author | Martin Braenne <mboehme@google.com> | 2023-05-22 06:17:55 +0000 |
|---|---|---|
| committer | Martin Braenne <mboehme@google.com> | 2023-05-22 06:51:15 +0000 |
| commit | 3bc1ea5b0ac90e04e7b935a5d964613f8fbad4bf (patch) | |
| tree | 631f0d9ffb0d5da779635dcb368570fefe9e05e8 /lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp | |
| parent | 96b22e1c378a93a26cd8fc8051bfc7b90f65b665 (diff) | |
[clang][dataflow] Fix a bug in handling of `operator->` for optional checker.
Prior to this patch, `operator->` was being handled like `operator*`: It was
associating a `Value` of type `T` with the expression result (where `T` is the
template argument of the `optional<T>`). This is correct for `operator*`, which
returns a reference (of some flavor) to `T`, so that the result of the
`CXXOperatorCallExpr` is a glvalue of type `T`. However, `operator*` returns a
`T*`, so the result of the `CXXOperatorCallExpr` is a prvalue `T*`, which should
therefore be associated with `PointerValue` that in turn refers to a `T`.
I noticed this issue while working on the migration to strict handling of
value categories (see https://discourse.llvm.org/t/70086). The current behavior
also seems problematic more generally because it's plausible that the framework
may at some point introduce behavior that assumes an `Expr` of pointer type is
always associated with a `PointerValue`.
As it turns out, this patch fixes an existing FIXME in the test
`OptionalValueInitialization`.
Depends On D150657
Reviewed By: ymandel
Differential Revision: https://reviews.llvm.org/D150775
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp')
0 files changed, 0 insertions, 0 deletions
