@@ -161,6 +161,34 @@ pub(crate) fn hash_crate_root_public_api(
161161 if !hcx. hash_public_api {
162162 return ;
163163 }
164+ // This must be matched exhaustively to help avoid subtle miscompiles when introducing new data
165+ // into rmeta.
166+ //
167+ // When a new field is added to `CrateRoot` the process of handling it in this function
168+ // should be the following:
169+ // 1. stable hash the values/query result serialized into the rmeta. For example if a new field
170+ // named `let my_new_field = self.encode_my_new_field();` is added to `CrateRoot` it
171+ // should be added here as
172+ // ```
173+ // // FIXME do we need this // or a comment about why we need this
174+ // let _ = my_new_field;
175+ // hasher.digest(tcx.query_my_new_field(), hcx); // or any other code that was that was used
176+ // // to get the encoded value in
177+ // // `encode_my_attribute_list`. We could
178+ // // decode it instead, but that is expensive.
179+ // ```
180+ // if the field was simple enough, like a bool, which does not need to be encoded
181+ // separately:
182+ // ```
183+ // // FIXME do we need this // or a comment about why we need this
184+ // hasher.digest(my_new_field);
185+ // ```
186+ //
187+ // 2. Add the comment "When changed, make sure to update the hashing in
188+ // `hash_crate_root_public_api`" into `encode_my_new_field`
189+ // 3. Only remove/change what is hashed in a separate PR. Removing items just from the hash
190+ // should be done with extreme scrutiny. A better way might be to sort the query result
191+ // in its provider, or filter which values we encode. That also helps with rmeta size.
164192 let CrateRoot {
165193 header,
166194 extra_filename,
0 commit comments