1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
//! Deciding where one residue ends and the next begins.
//!
//! The file does not say. It gives every atom a set of annotations, and a
//! residue is a run of atoms that agree on them — so the whole question is which
//! annotations count.
//!
//! Two rules come from files that broke naive readers:
//!
//! - The component code is **excluded** from the key. One alternate location of
//! a residue may carry a different component code, because a point mutation
//! was modelled; that is one residue with two chemical identities, not two
//! residues, and including the code in the key splits it.
//! - Where the annotations do not distinguish two adjacent groups at all, the
//! caller must either reject the ambiguity or explicitly permit file-order
//! inference. Real entries exist where consecutive residues carry identical
//! annotations, and a reader that trusts the annotations merges them silently.
use OptionalI32;
/// What identifies a residue, and therefore where its boundaries fall.
///
/// The component code is deliberately absent. Everything here is an interned
/// identifier or a number, so comparing two keys is integer work.
/// Whether a new atom starts a new residue, and whether saying so needed a guess.
/// Decides whether `next` continues the residue `current` describes.
///
/// `repeats_atom_name` says whether the incoming atom's name has already been
/// seen in the residue being filled, which is what betrays a boundary the
/// annotations do not mark.