near / nearcore

Reference client for NEAR Protocol

Home Page:https://near.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

/cc @jakmeier @wacban

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.

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

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.