Fix deprecation warning of unscheduled circuits in timeline drawer

[jakelishman]

Summary

The warning was previously emitted with a stacklevel that blamed the caller of warnings.warn, which would not be shown to users with the default warning filters. This moves the stack level up to blame the caller of timeline_drawer.

Details and comments

I updated some documentation still using the old paths here, but in looking at it, I'm not 100% sure that:

• the new PadDynamicalDecoupling also adds node start times to anything new it inserts in a way that the visualiser will understand
• we shouldn't just make the old-style schedulers save this information as well so the ugly draw wrapper in the (legacy) DynamicalDecoupling pass is unnecessary.

I'm not at all familiar with this code though, so I don't know what's best on it.

[qiskit-bot]

One or more of the the following people are requested to review this:

• @enavarro51
• @Qiskit/terra-core
• @nkanazawa1989

[coveralls]

Pull Request Test Coverage Report for Build 6207977535

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 11 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.001%) to 87.272%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	5	91.41%
crates/qasm2/src/parse.rs	6	97.6%

Totals
Change from base Build 6204306855:	0.001%
Covered Lines:	74195
Relevant Lines:	85016

---

💛 - Coveralls

[ElePT]

LGTM, I just have a small question.

[ElePT]

Just to confirm, the use of stacklevel=3 is so that the warning points to timeline_drawer, correct? Asking because most of our deprecation warnings are stacklevel=2.

[jakelishman]

Yeah, in this case it's a higher stack level because the function that triggers the warning is a "helper" function to the public API, so we need to unwind one extra stack frame before blaming it. The idea is that warnings.warn(stacklevel=n) blames the code n calls above warnings.warn for being wrong. So stacklevel=1 (the default) blames the caller of warn, and stacklevel=2 blames the caller of the caller of warn. In public-library code, that's usually the API entry point, because it's usually entry points' jobs to normalise inputs and issue deprecation warnings. When we use a helper function to unify the warning logic, the stack level often rises to 3, because the entry point calls the helper, which calls warn, and it was still the user's fault.

In this case, load_program is kind of public API itself, but in practice the user entry point is almost invariable timeline.draw. The worst that happens if the stack level is too high, though, is that some other code a level higher than the user's function (which is almost certainly still user code) gets blamed instead, so it should still show.

[ElePT]

Thanks for the detailed explanation, LGTM!