Skip to content

Fix tracking of parameters in instances of QkTargetOp #15438

@raynelfss

Description

@raynelfss

What should we add?

Currently we are returning conflicting information when retreiving a parametric operation using qk_target_op_get:

In rust we have

#[repr(C)]
struct CTargetOp {
    ...
    params: *mut f64 // Returns a list of all fixed parameters.
    num_params: u32 // Represents the number of parameters supported by the operation.
    ....
}

One idea suggested by @jakelishman:

The logic here doesn't result in a boxed slice that's necessarily num_params entries long; it's only valid in C because we didn't provide a way to only specify partially fixed parameters yet. Once Targets can be created (say) by the Python interface and given to C (e.g. #15337), we can't get away with that kind of assumption in the C API any more, so we'll have to handle it.

[...], but let's take a follow-up issue to (for example) use f64::NAN as a marker for "arbitrary" so the slice is definitely going to be the correct length and C space will be able to tell.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status

    Ready

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions