Unsupported native gates

[csookim]

Unroller generates an error when initialized with unsupported gates.

https://github.com/qiboteam/qibolab/actions/runs/11569426877/job/32203123767?pr=1083#step:10:259

In this PR, when qibo receives native gates, unsupported gates will be ignored. Should we require backends to match qibo’s native gate set?

Checklist:

• Reviewers confirm new code works as expected.
• Tests are passing.
• Coverage does not decrease.
• Documentation is updated.

qiboteam/qibolab#1083

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.74%. Comparing base (a074d17) to head (23423a9).
Report is 24 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1504   +/-   ##
=======================================
  Coverage   99.74%   99.74%           
=======================================
  Files          80       80           
  Lines       11768    11772    +4     
=======================================
+ Hits        11738    11742    +4     
  Misses         30       30           

Flag	Coverage Δ
unittests	99.74% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alecandido]

Ok, it should be fine to ignore the native gates which are unsupported, and restrict to the known ones. The alternative is just failing, but this is what it would happen anyhow if the restricted set of natives won't allow you to transpile (to save computation, we may introduce ahead of time checks, but if there is no way to tell it in advance, attempting and failing is just the best we could do).

I'm not sure which is the practical motivation in this case (I guess coming from Qibolab), which instead may be worth to address even in a separate way (though this is still fine to me).
@stavros11 do you see any major drawback in this approach?

[stavros11]

If I understand this correctly, the motivation is to avoid failure when the qibolab platform/compiler provides more native gates than the transpiler "knows". In that case, transpilation should still be possible using the intersection of gates supported by the transpiler and compiler/platform.

Other than the fact that it may be a bit suboptimal, as I would expect the gate limitation to come primarily from the hardware, not the transpiler, I do not see any major drawback so I am approving.