From: Matt Corallo Date: Fri, 1 Jan 2021 01:19:21 +0000 (-0500) Subject: [bindings] Use consistent imports for MessageSendEvents traits X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=commitdiff_plain;h=1d3e71fc7086874bdeae52f93cc950e570d5bc06;p=rust-lightning [bindings] Use consistent imports for MessageSendEvents traits Our bindings generator is braindead with respect to the idents used in a trait definition - it treats them as if they were used where the trait is being used, instead of where the trait is defined. Thus, if the idents used in a trait definition are not also imported the same in the files where the traits are used, we will claim the idents are bogus. I spent some time trying to track the TypeResolvers globally through the entire conversion run so that we could use the original file's TypeResolver later when using the trait, but it is somewhat of a lifetime mess. While likely possible, import consistency is generally the case anyway, so unless it becomes more of an issue in the future, it likely makes the most sense to just keep imports consistent. This commit keeps imports consistent across trait definition files around `MessageSendEvent` and `MessageSendEventsProvider`. --- diff --git a/lightning/src/ln/msgs.rs b/lightning/src/ln/msgs.rs index 25553c708..8517e85d8 100644 --- a/lightning/src/ln/msgs.rs +++ b/lightning/src/ln/msgs.rs @@ -35,7 +35,7 @@ use ln::features::{ChannelFeatures, InitFeatures, NodeFeatures}; use std::{cmp, fmt}; use std::io::Read; -use util::events; +use util::events::MessageSendEventsProvider; use util::ser::{Readable, Writeable, Writer, FixedLengthReader, HighZeroBytesDroppedVarInt}; use ln::channelmanager::{PaymentPreimage, PaymentHash, PaymentSecret}; @@ -746,7 +746,7 @@ pub enum OptionalField { /// /// Messages MAY be called in parallel when they originate from different their_node_ids, however /// they MUST NOT be called in parallel when the two calls have the same their_node_id. -pub trait ChannelMessageHandler : events::MessageSendEventsProvider + Send + Sync { +pub trait ChannelMessageHandler : MessageSendEventsProvider + Send + Sync { //Channel init: /// Handle an incoming open_channel message from the given peer. fn handle_open_channel(&self, their_node_id: &PublicKey, their_features: InitFeatures, msg: &OpenChannel); @@ -810,7 +810,7 @@ pub trait ChannelMessageHandler : events::MessageSendEventsProvider + Send + Syn /// For `gossip_queries` messages there are potential DoS vectors when handling /// inbound queries. Implementors using an on-disk network graph should be aware of /// repeated disk I/O for queries accessing different parts of the network graph. -pub trait RoutingMessageHandler : Send + Sync + events::MessageSendEventsProvider { +pub trait RoutingMessageHandler : Send + Sync + MessageSendEventsProvider { /// Handle an incoming node_announcement message, returning true if it should be forwarded on, /// false or returning an Err otherwise. fn handle_node_announcement(&self, msg: &NodeAnnouncement) -> Result; diff --git a/lightning/src/routing/network_graph.rs b/lightning/src/routing/network_graph.rs index 8075462c9..4b53a21ba 100644 --- a/lightning/src/routing/network_graph.rs +++ b/lightning/src/routing/network_graph.rs @@ -29,7 +29,7 @@ use ln::msgs::{QueryChannelRange, ReplyChannelRange, QueryShortChannelIds, Reply use ln::msgs; use util::ser::{Writeable, Readable, Writer}; use util::logger::Logger; -use util::events; +use util::events::{MessageSendEvent, MessageSendEventsProvider}; use std::{cmp, fmt}; use std::sync::{RwLock, RwLockReadGuard}; @@ -64,7 +64,7 @@ pub struct NetGraphMsgHandler where C::Target: chain::Access pub network_graph: RwLock, chain_access: Option, full_syncs_requested: AtomicUsize, - pending_events: Mutex>, + pending_events: Mutex>, logger: L, } @@ -244,7 +244,7 @@ impl RoutingMessageHandler for N let number_of_blocks = 0xffffffff; log_debug!(self.logger, "Sending query_channel_range peer={}, first_blocknum={}, number_of_blocks={}", log_pubkey!(their_node_id), first_blocknum, number_of_blocks); let mut pending_events = self.pending_events.lock().unwrap(); - pending_events.push(events::MessageSendEvent::SendChannelRangeQuery { + pending_events.push(MessageSendEvent::SendChannelRangeQuery { node_id: their_node_id.clone(), msg: QueryChannelRange { chain_hash: self.network_graph.read().unwrap().genesis_hash, @@ -279,7 +279,7 @@ impl RoutingMessageHandler for N log_debug!(self.logger, "Sending query_short_channel_ids peer={}, batch_size={}", log_pubkey!(their_node_id), msg.short_channel_ids.len()); let mut pending_events = self.pending_events.lock().unwrap(); - pending_events.push(events::MessageSendEvent::SendShortIdsQuery { + pending_events.push(MessageSendEvent::SendShortIdsQuery { node_id: their_node_id.clone(), msg: QueryShortChannelIds { chain_hash: msg.chain_hash, @@ -327,12 +327,12 @@ impl RoutingMessageHandler for N } } -impl events::MessageSendEventsProvider for NetGraphMsgHandler +impl MessageSendEventsProvider for NetGraphMsgHandler where C::Target: chain::Access, L::Target: Logger, { - fn get_and_clear_pending_msg_events(&self) -> Vec { + fn get_and_clear_pending_msg_events(&self) -> Vec { let mut ret = Vec::new(); let mut pending_events = self.pending_events.lock().unwrap(); std::mem::swap(&mut ret, &mut pending_events);