yeast: Add context scoping mechanism

[tausbn]

An addendum to #22120. Removes translate_reset in favour of a mechanism that is a bit less "all or nothing".

The main addition is a new method ctx.scoped which takes a closure as an argument. Thus, where we previously wrote

let val = ctx.translate_reset(val)?;

with translate_reset taking care of nuking the entire user_ctx, we now instead write

let val = ctx.scoped(|ctx| {
    ctx.reset();
    ctx.translate(val)
})?;

Note that in particular, reset is now a method on SwiftContext, not something that the yeast framework provides. This means we can easily make it more fine-grained, e.g. replacing it with a method that just resets the current modifiers.

Also, for cases where we don't need ctx after doing the translation, we can simply call ctx.reset() without the scope -- the changes to the context are prevented from bleeding through by means of the existing context isolation mechanism.

---

Should be reviewed commit-by-commit. The final commit changes the isolation mechanism from "save and then restore" to "clone and then drop", which saves some unnecessary work, and is otherwise just as good.

[Copilot]

Pull request overview

This PR updates the Yeast translation framework and Swift extractor rules to replace the previous “reset the entire user context” helper with an explicit, more fine-grained scoping mechanism. It introduces BuildCtx::scoped for temporary context mutation (without leaking changes) and moves “reset” semantics into the Swift-specific SwiftContext::reset, aligning the framework with language-specific needs.

Changes:

• Add BuildCtx::scoped(...) to run a closure with a temporary child context backed by a cloned user_ctx, discarding mutations on return.
• Change Yeast’s context isolation implementation from “clone + restore” to “clone + drop” per rule attempt.
• Update Swift translation rules to use SwiftContext::reset() plus ctx.scoped(...) where the outer context must remain intact after translating a reset subtree.

Show a summary per file

File	Description
unified/extractor/src/languages/swift/swift.rs	Adds SwiftContext::reset and replaces translate_reset usage with explicit reset + optional ctx.scoped(...) to avoid context leakage while preserving needed outer context.
shared/yeast/src/lib.rs	Adds Id: IntoIterator (singleton), makes translator handles Copy unconditionally, and switches rule context isolation to “clone and drop” for simpler, ?-safe non-leaking behavior.
shared/yeast/src/build.rs	Updates BuildCtx::translate to accept any iterable of ids (including a bare Id) and introduces BuildCtx::scoped for temporary child-context execution.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Low

[jketema]

Two questions, and I believe I spotted a typo.

[jketema]

This begs the question: why do we need scoped here, but not in any of the other places where we had translate_reset before?

[tausbn]

The difference here is that we want to use ctx (or more specifically the user-controlled user_ctx field on it -- which through some Deref magic is directly accessible on ctx itself) further down in the body of this rule. When we get to ctx.translate(obs), we want that user context to not have been reset. But we've already put var_decl into the result, and this required var to have been translated.

Thus, we have to introduce a temporary context -- or at least it's the easiest way to get the desired behaviour. (I guess technically we could do the var stuff at the end, and then prepend it onto result but I think that's less clear than the current implementation.)

[jketema]

Let me rephrase, because that's not really helping me. I assume that a context here roughly corresponds to some type of scope in Swift. If so, from the perspective of the Swift AST, what is different here than in the other cases where we had translate_reset.

[tausbn]

The context is a mechanism for passing information from a node down to its descendants. For instance, In some cases we have an outer type that we want to propagate down into some descendant. In this case, we set the appropriate part of the SwiftContext (which is just a struct that we can choose the content of), specifically the following field:

codeql/unified/extractor/src/languages/swift/swift.rs

Line 23 in 33da3ef

property_type: Option<yeast::Id>,

In the previous code, we had two different kinds of translate_reset calls. The simple uses just had things like

(accessor_declaration
  body: (block stmt: {ctx.translate_reset(body)?})
)

This had the effect of translating body within an empty context. (That is, it temporarily saves the current context, then creates an empty context, runs the translation, and then restores the saved context.)

But in this case, there's no reason to restore the context -- it gets dropped anyway afterwards, which is why we can just rewrite it to use reset and then the normal translate.

(accessor_declaration
  body: (block stmt: {ctx.reset(); ctx.translate(body)?})
)

The difficult case is the following (eliding the unimportant bits):

// previously: val = translate_reset(val)?;
let val = ctx.scoped(|ctx| {
    ctx.reset();
    ctx.translate(val)
})?;

let var_decl = tree!(
    (variable_declaration
        modifier: {ctx.outer_modifiers.clone()}
        modifier: {chained_modifier(&mut ctx)}
        pattern: (name_pattern identifier: (identifier #{name}))
        type: {ty}
        value: {val})
);

// Publish the property name for the observer rules.
ctx.property_name = Some(tree!((identifier #{name})));
// Observers are subsequent outputs of this flattening
// rule, so they always get `chained_declaration`.
ctx.is_chained = true;

let mut result = vec![var_decl];
for obs in ws.into_iter().chain(ds) {
    result.extend(ctx.translate(obs)?);
}
result

The behaviour is the same as before -- we just express it slightly differently. The important thing is that when we do ctx.translate(val) we need the context to be cleared, otherwise things get translated incorrectly. However, when we do ctx.translate(obs), it shouldn't be cleared (or at least, that's the current behaviour). So, currently we use translate_reset to provide a temporary empty context for the val translation, and for the rewrite we explicitly call ctx.scoped, which allows us to make any changes to ctx that we like without it affecting anything outside the scope.