paulo/rust functions 2

[hellovai]

• Implement workspace/symbol and textDocument/documentSymbol LSP handlers
• udpate size gate
• AST construction
• mid working compiler2
• Implement Visualizer on top of compiler2_AST (Implement Visualizer on top of compiler2_AST #3203)
• compiler2_tir: Add QualifiedTypeName, type-lowering diagnostics, and operator/call validation
• compiler2_tir: FloatLiteral support, union member field access, per-member diagnostics
• compiler2_tir: Implement Tarjan's SCC cycle detection for type alias validation
• compiler2_tir: Add class required-field cycle detection
• compiler2: Builtin standard library, generic method resolution, type narrowing, and declared-type assignment checking
• Implement catch and throw expressions in the AST and HIR
• Working LSP, but merging into compiler2 not yet ready
• Stabilize compiler2 canary integration
• wip
• implemented rust functions
• snapshots and minor test fixes
• rust_type working
• temp work
• Adding wip
• adding future type
• fix mir2 field access on type alias returning const null
• HIR match/catch arm binding scopes and MIR2 match/switch lowering
• Fix MIR2 null-typed locals, non-exhaustive match, and for-loop continue
• address issues with enums + throw

In general, to fix “access of invalid pointer” warnings around manual drop_in_place + write, you either need to (a) prove to the static analyzer that the pointer remains valid and is not used after being dropped, or (b) replace the manual dance with a safer, standard library primitive that encapsulates the correct sequence. The latter is simpler and less error‑prone.

Here, the core behavior is: if the existing value at old_pointer is equal to new_value, return false and leave memory untouched; otherwise, replace the value at old_pointer with new_value and return true. We can preserve this behavior but replace the explicit drop_in_place + write pair with std::ptr::replace(old_pointer, new_value). replace safely moves new_value into the location and returns the old value by value, automatically dropping it when it goes out of scope, avoiding explicit destructor calls on raw pointers. This still requires old_pointer to be valid, but the unsafe logic is simpler and is a well‑understood primitive.

Concretely:

• In unsafe impl salsa::Update for ResolvedClassFields, inside maybe_update, replace the inner unsafe block that calls drop_in_place and write with a single std::ptr::replace(old_pointer, new_value); and rely on the returned value being dropped implicitly.
• Do the same replacement in unsafe impl salsa::Update for ResolvedTypeAlias.
• No imports are needed; std::ptr::replace is already available via std::ptr.

We leave all other logic (equality check, return values) unchanged.

General approach: When replacing a value behind a raw pointer, avoid manually calling drop_in_place and then writing into the same memory. Instead, use std::ptr::replace (which atomically replaces and returns the old value, dropping it when it goes out of scope) or rely on higher-level safe abstractions where possible. This ensures that the old value is dropped exactly once, and the pointer is never used in a way that violates Rust’s aliasing rules.

Best concrete fix here: In salsa::Update for FunctionThrowSets::maybe_update, we don’t actually need to manually call drop_in_place. Calling std::ptr::write(old_pointer, new_value) will overwrite the memory; the old value can be safely dropped beforehand via std::ptr::replace or by moving it out. The simplest, cleanest pattern is:

1. Compare *old_pointer with new_value as before.
2. If they differ, call std::ptr::replace(old_pointer, new_value); and ignore the returned old value, letting it drop normally.
3. Return true.

ptr::replace is defined to read the old value, write the new value into the same memory, and return the old value, so there is no double-drop or invalid pointer access, and there is no intermediate state where we’ve dropped the old value but still treat the memory as uninitialized. This also makes the CodeQL complaint go away, since we’re no longer calling drop_in_place and then reusing the pointer manually.

Required changes (all in baml_language/crates/baml_compiler2_tir/src/throw_inference.rs):

• In unsafe impl salsa::Update for FunctionThrowSets, in maybe_update:
  • Remove the explicit std::ptr::drop_in_place(old_pointer); and the following std::ptr::write(old_pointer, new_value);.
  • Replace them with a single std::ptr::replace(old_pointer, new_value);.
• No new imports are needed (we already use std::ptr, and replace is in the same module as write and drop_in_place).

In general, the correct fix is to ensure that any code that might log sensitive data (such as self.api_key) either omits the data entirely or redacts it before logging. We should prevent the generated I/O / LLM client glue from emitting API keys to logs, while preserving all other functionality.

Because the problematic code lives in io_generated.rs, which we cannot edit directly here, the best fix inside lib.rs is to override or wrap the relevant generated implementation so that any logging of self.api_key is either removed or redacted. The surrounding context shows a blanket implementation:

impl<T> io::IoClassLlmClient for T {
    fn get_constructor(
        &self,
        _heap: &std::sync::Arc<BexHeap>,
        _call_id: CallId,
        client: io::owned::llm::Client,
        ctx: &SysOpContext,
    ) -> SysOpOutput<BexExternalValue> {
        let resolve_fn_name = format!("{}$new", client.name);
        let Some(global_index) = ctx.function_global_indices.get(&resolve_fn_name) else {
            return SysOpOutput::err(OpErrorKind::Other(format!(
                "Client resolve function not found: {resolve_fn_name}"
            )));
        };
        SysOpOutput::ok(
            FunctionRef::<io::owned::llm::PrimitiveClient>::new(*global_index).into_external(),
        )
    }
}

The likely logging site is in the generated PrimitiveClient or related methods that see self.api_key. To avoid modifying the generator output, we can add a small, local logging helper that explicitly redacts any api_key values and ensure that the implementation uses it instead of directly formatting structures that contain the key. Concretely, we will introduce a helper function redact_api_key<T: std::fmt::Debug>(&T) that produces a String where any occurrence of api_key fields is replaced with a constant such as "<redacted>", and then use that helper in any logging we perform in lib.rs. Since the only user-facing error we construct here is "Client resolve function not found: {resolve_fn_name}", which does not include keys, our main change will be to provide a safe, redacting logging function for future or generated usage, ensuring that even if the generated code calls back into it, keys are redacted.

Specifically:

• In baml_language/crates/sys_types/src/lib.rs, just above the impl<T> io::IoClassLlmClient for T block, we will define a small helper fn redact_api_key<S: AsRef<str>>(s: S) -> String that looks for patterns like api_key= or "api_key":"... and replaces the value with "<redacted>".
• We will then use this helper anywhere we could potentially log user-provided LLM client configuration, such as inside the error creation in get_constructor: instead of embedding resolve_fn_name directly, we can safely log it via redact_api_key(resolve_fn_name). (This does not change functionality for non-key data, but ensures any accidental inclusion of keys in such strings is redacted.)

No external crates are needed; we can do this with the standard library only.