Release master doesn't build: no method named `debug_check_unchanged` found for reference `&DelayedReceiptQueue`
jancionear opened this issue · comments
Trying to do a release build on the current master (400bdf1) fails.
$ cargo build -p neard --release
Compiling neard v0.0.0 (/home/jan/code/nearcore/neard)
Compiling near-jsonrpc-client v0.0.0 (/home/jan/code/nearcore/chain/jsonrpc/client)
Compiling near-store v0.0.0 (/home/jan/code/nearcore/core/store)
error[E0599]: no method named `debug_check_unchanged` found for mutable reference `&mut DelayedReceiptQueue` in the current scope
--> core/store/src/trie/receipts_column_helper.rs:41:18
|
41 | self.debug_check_unchanged(state_update);
| ^^^^^^^^^^^^^^^^^^^^^ method not found in `&mut DelayedReceiptQueue`
error[E0599]: no method named `debug_check_unchanged` found for mutable reference `&mut DelayedReceiptQueue` in the current scope
--> core/store/src/trie/receipts_column_helper.rs:55:18
|
55 | self.debug_check_unchanged(state_update);
| ^^^^^^^^^^^^^^^^^^^^^ method not found in `&mut DelayedReceiptQueue`
error[E0599]: no method named `debug_check_unchanged` found for reference `&DelayedReceiptQueue` in the current scope
--> core/store/src/trie/receipts_column_helper.rs:80:18
|
80 | self.debug_check_unchanged(trie);
| ^^^^^^^^^^^^^^^^^^^^^ method not found in `&DelayedReceiptQueue`
For more information about this error, try `rustc --explain E0599`.
error: could not compile `near-store` (lib) due to 3 previous errors
warning: build failed, waiting for other jobs to finish...
The error originates from this function, added in #11159:
/// Check the queue has not been modified in the trie view.
///
/// This is a semi-expensive operation. The values should be cached in
/// memory in at least one layer. But we still want to avoid it in
/// production.
#[cfg(debug_assertions)]
fn debug_check_unchanged(&self, trie: &dyn TrieAccess) {
debug_assert_eq!(
self.indices,
get(trie, &TrieKey::DelayedReceiptIndices).unwrap().unwrap_or_default()
);
}
Recently we also had some feature changes, could be related: #11158
Pretty sure this is my bad. (Plus CI letting my PR through is not ideal, either...)
I should have a fix in a minute. Or you can revert if you want.
Fix in: #11164
Please take a look. It's a simple mistake of using compile time flags in a runtime if, this one always gets me^^
Yeah the problem is already present at a49de7d, looks like #11158 had nothing to do with it
Plus CI letting my PR through
👍, that's weird, I though that we do a release build somewhere in the CI 0_o
I guess we use an "almost" release profile that still has debug_assertions enabled.