Add type-safe VecMap for slices indexed by newtypes

[jakelishman]

Sabre uses several objects that are logically maps from an index-like newtype (like NodeIndex or PhysicalQubit) to some value, and are implemented as fixed-slice Vecs for lookup efficiency. The newtype provides type safety while it's in use, but we have to cast it away to index, which makes it easy to index slices with the wrong object.

This introduces a VecMap object, which provides a (minimal) slice-like interface, but indexes using the relevant newtype.

The current implementation of Sabre does not use this too much, but a refactoring of the layer structures will have them store one slice indexed by PhysicalQubit and one by VirtualQubit, which are trivially easy to get switched (a frequent mistake that is the base reason those new types were introduced in the first place).

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 16969142707

Details

• 151 of 160 (94.38%) changed or added relevant lines in 6 files are covered.
• 27 unchanged lines in 6 files lost coverage.
• Overall coverage decreased (-0.006%) to 88.252%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/transpiler/src/passes/sabre/route.rs	112	115	97.39%
crates/circuit/src/nlayout.rs	0	6	0.0%

Files with Coverage Reduction	New Missed Lines	%
crates/circuit/src/parameter/parameter_expression.rs	1	83.39%
crates/transpiler/src/passes/sabre/dag.rs	1	96.97%
crates/transpiler/src/passes/sabre/route.rs	3	93.93%
crates/qasm2/src/lex.rs	4	92.01%
crates/circuit/src/parameter/symbol_expr.rs	6	74.5%
crates/qasm2/src/parse.rs	12	97.09%

Totals
Change from base Build 16967470304:	-0.006%
Covered Lines:	87850
Relevant Lines:	99544

---

💛 - Coveralls

[jakelishman]

Sasha: this is next (with #15897). I think, after this, I have to look again in more detail at the next two PRs because it seems like one of them introduces a non-determinism or a platform dependency.

This one is fine, though (without it, I for sure would have made mistakes in writing #14911).

There'll be a minor merge conflict with #15897 - the solution will be to take the hunk from #15897 and ignore this PR.

[alexanderivrii]

This is a cool PR!

So basically previously we could write code like

my_data: Vec<f64> // should be indexed by physical qubits
v: VirtualQubit
my_data[v.index()] = ... 

and it would compile, but now we would write

my_data: VecMap<PhysicalQubit, f64> 
v: VirtualQubit
my_data[v] = ... 

and it would not compile (preventing the error).

My only question is whether the new VecMap struct should be exposed to more of Qiskit and not local to sabre?

[jakelishman]

My only question is whether the new VecMap struct should be exposed to more of Qiskit and not local to sabre?

It could be. If you prefer, I can move it into the root of transpiler?

[alexanderivrii]

It could be. If you prefer, I can move it into the root of transpiler?

We don't need to move this for this PR at all, but would this be a natural fit for the new utils crate that you have added?

[jakelishman]

The awkward bit about putting it in utils is that it depends on petgraph's IndexType trait right now, and it'd be a bit weird to put a dependency on petgraph into the utils crate. It probably wouldn't have any meaningful impact, since circuit depends on petgraph anyway, but it still feels odd.

[alexanderivrii]

Thanks!