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
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
//! Subtype resolution without loading the EXPRESS schema at runtime.
//!
//! The tables encode two releases, listed in [`VERIFIED_SCHEMA_VERSIONS`]:
//! IFC4 ADD2 TC1, the base ([`TABLE_SCHEMA_VERSION`]), and IFC4X3 ADD2 as a
//! delta over it. [`is_a_in`] and [`supertypes_of_in`] answer for one named
//! release; ask [`tables_are_verified_for`] before trusting them for another.
//!
//! # Why this table exists
//!
//! EXPRESS `SELECT` types name *abstract* supertypes. `IfcBooleanOperand`
//! permits `IfcSolidModel`, but no file contains one -- files contain
//! `IfcExtrudedAreaSolid`, four levels below it. Answering "may this entity
//! stand in for that select member" therefore needs the inheritance chain.
//!
//! `ifc-schema` can parse the official `.exp` files and answer exactly this,
//! but requiring it would mean a geometry consumer must ship a 3 MB schema
//! file to interpret a wall. The chains for the geometry-reachable entities
//! are small and change only when the IFC schema does, so they are compiled in
//! as data.
//!
//! # Why the releases are separate rows, not one merged table
//!
//! IFC4X3 does not only add entities. It also inserts abstract supertypes
//! above four IFC4 entities: `IfcOffsetCurve2D` and `IfcOffsetCurve3D` gain
//! `IfcOffsetCurve`, `IfcFixedReferenceSweptAreaSolid` and
//! `IfcSurfaceCurveSweptAreaSolid` gain `IfcDirectrixCurveSweptAreaSolid`.
//! One merged chain for those names would be wrong for one release or the
//! other, so the IFC4X3 rows that differ live apart and are used only when a
//! caller names IFC4X3.
//!
//! The unversioned [`is_a`] and [`supertypes_of`] answer the IFC4 chain for
//! every entity IFC4 declares, exactly as before IFC4X3 rows existed, and the
//! IFC4X3 chain for entities only IFC4X3 declares. A name IFC4 lacks cannot
//! occur in an IFC4 file, so that fallback changes no IFC4 answer. The only
//! IFC4X3 answers it misses are the inserted abstract supertypes above: no
//! select or rule in this crate asks for them, and [`is_a_in`] answers them.
//!
//! # Keeping it honest
//!
//! Generated from `IFC4.exp` and `IFC4X3_ADD2.exp`. `tests/schema_coverage.rs`
//! compares every chain, per release, with the same normative sources, so
//! drift fails the build rather than silently misclassifying a solid.
use SchemaVersion;
use SUPERTYPES;
use subtype_ifc4x3;
/// The base release of the compiled tables.
///
/// The unversioned [`is_a`] and [`supertypes_of`] answer this release's chain
/// for every entity it declares. [`VERIFIED_SCHEMA_VERSIONS`] lists every
/// release [`is_a_in`] answers verbatim.
pub const TABLE_SCHEMA_VERSION: SchemaVersion = Ifc4;
/// Every release whose chains the compiled tables carry verbatim.
pub const VERIFIED_SCHEMA_VERSIONS: & =
&;
/// Does [`is_a_in`] answer subtype questions for `version` verbatim?
///
/// True for IFC4 and IFC4X3. False does not mean refusal: IFC4X1 and IFC4X2
/// share most geometry chains with these, so the unversioned answers
/// [`is_a_in`] falls back to are usually right. It means they are not
/// *verified* against that schema, and a caller that needs certainty must say
/// so.
/// Is `entity` the named type, or any subtype of it?
///
/// The question every EXPRESS `SELECT` resolution reduces to. Comparing type
/// names directly instead of calling this rejects every real file, because
/// select members are usually abstract.
///
/// Release-neutral: answers the IFC4 chain where IFC4 declares `entity`, and
/// the IFC4X3 chain where only IFC4X3 does (see the module docs). Use
/// [`is_a_in`] to ask about one release exactly.
///
/// ```
/// use ifc_geometry::select::is_a;
/// // An extruded area solid IS a solid model, four levels up.
/// assert!(is_a("IFCEXTRUDEDAREASOLID", "IFCSOLIDMODEL"));
/// assert!(!is_a("IFCCARTESIANPOINT", "IFCSOLIDMODEL"));
/// // IFC4X3-only entities resolve too.
/// assert!(is_a("IFCCLOTHOID", "IFCCURVE"));
/// ```
/// Is `entity` the named type, or any subtype of it, in `version`?
///
/// Exact for every release [`tables_are_verified_for`] accepts; other
/// releases get the release-neutral [`is_a`] answer.
///
/// ```
/// use ifc_geometry::select::is_a_in;
/// use ifc_schema::SchemaVersion;
/// // IFC4X3 inserts IfcOffsetCurve above IfcOffsetCurve2D; IFC4 has none.
/// assert!(is_a_in(SchemaVersion::Ifc4x3, "IFCOFFSETCURVE2D", "IFCOFFSETCURVE"));
/// assert!(!is_a_in(SchemaVersion::Ifc4, "IFCOFFSETCURVE2D", "IFCOFFSETCURVE"));
/// ```
/// The supertype chain of an entity, immediate parent first.
///
/// Release-neutral, as [`is_a`]. Empty for an unknown entity: a type from a
/// newer schema is not an error, it simply matches no select, which is the
/// correct conservative answer.
/// The supertype chain of an entity in `version`, immediate parent first.
///
/// Exact for every release [`tables_are_verified_for`] accepts, and empty for
/// an entity that release does not declare. Other releases get the
/// release-neutral [`supertypes_of`] answer.
/// Every entity this table knows, for cross-checking against the schema.
///
/// The union over [`VERIFIED_SCHEMA_VERSIONS`], each name once.
/// Every entity `version` declares in these tables; empty for a release
/// [`tables_are_verified_for`] rejects.
type Row = ;