[all-commits] [llvm/llvm-project] f33b28: [lldb] Consult Policy for expression evaluation ca...

[Med Ismail Bennani via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f33b28a6979d6db40096da872befbf923357c322
      https://github.com/llvm/llvm-project/commit/f33b28a6979d6db40096da872befbf923357c322
  Author: Med Ismail Bennani <ismail at bennani.ma>
  Date:   2026-09-24 (Thu, 24 Sep 2026)

  Changed paths:
    M lldb/include/lldb/Target/Process.h
    M lldb/source/Expression/UserExpression.cpp
    M lldb/source/Target/Process.cpp
    M lldb/source/Target/Target.cpp
    M lldb/source/Utility/Policy.cpp
    M lldb/unittests/Utility/PolicyTest.cpp

  Log Message:
  -----------
  [lldb] Consult Policy for expression evaluation capabilities (#225312)

`can_evaluate_expressions`, `can_run_all_threads` and
`can_try_all_threads` have been unused since 3fe311f215d0 added them:
nothing outside `Policy.h` and its unit test ever read them.

Two of them already had a hand-rolled equivalent, though.
`Target::EvaluateExpression` forces single-threaded execution while a
frame provider is active, which is what the two thread capabilities
describe. That check predates them by six weeks (e1cd55879b5f) and the
adoption patch never came back for it. Living in `Target` also means it
only sees expressions that go through `Target`, not the ones coming from
`FunctionCaller` or `IRInterpreter`.

This patch changes that to consult the capabilities where the decision
is actually made: `UserExpression::Evaluate` for
`can_evaluate_expressions`, and `RunThreadPlan` for the other two. The
Target check goes away.

`RunThreadPlan` refuses rather than rewrites. Clearing stop-others asks
for the other threads, and since that option defaults to true, clearing
it is deliberate, so it errors instead of being silently turned back on.
Asking for the all-threads retry is refused the same way. The retry is
still switched off quietly when the caller never asked for it, since
that option defaults to on and so says nothing about intent.

It also checks the thread capabilities in `CreateScriptedExtensionCall`
rather than somewhere frame-provider specific. Not altering the state
you were asked to describe applies to any extension the debugger calls
into, so this increases the scope of the check it replaces: synthetic
children, OS plugin thread lists and scripted thread plans are now
covered too.

Since scripted commands set `UserCanRunDirectly` to true, the
`ScriptedExtensionCall` policy never gets pushed, so these expression
evaluation capabilities are kept and that is the behavior we want: the
user invoked the command directly, so there is no debugger operation
already in flight whose state it could alter.

rdar://176223894

Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>



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