Address various rustc warnings
Change-Id: I61bbfcdbbbb9a4795e2c280f70903e1b66a165c9
Signed-off-by: James Kuszmaul <james.kuszmaul@bluerivertech.com>
diff --git a/aos/events/event_loop_runtime.rs b/aos/events/event_loop_runtime.rs
index de5c636..18d743e 100644
--- a/aos/events/event_loop_runtime.rs
+++ b/aos/events/event_loop_runtime.rs
@@ -22,7 +22,7 @@
//! future".
//! 3. Multiple applications are better suited to multiple `EventLoopRuntime`s, on separate
//! `aos::EventLoop`s. Otherwise they can't send messages to each other, among other
-//! restrictions. https://github.com/frc971/971-Robot-Code/issues/12 covers creating an adapter
+//! restrictions. <https://github.com/frc971/971-Robot-Code/issues/12> covers creating an adapter
//! that provides multiple `EventLoop`s on top of a single underlying implementation.
//!
//! ## Design
@@ -31,7 +31,7 @@
//! considerations in arriving at this design include:
//! * `EventLoop` implementations alias the objects they're returning from C++, which means
//! creating Rust unique references to them is unsound. See
-//! https://github.com/google/autocxx/issues/1146 for details.
+//! <https://github.com/google/autocxx/issues/1146> for details.
//! * For various reasons autocxx can't directly wrap APIs using types ergonomic for C++. This and
//! the previous point mean we wrap all of the C++ objects specifically for this class.
//! * Rust's lifetimes are only flexible enough to track everything with a single big lifetime.
@@ -40,7 +40,7 @@
//! * We can't use [`futures::stream::Stream`] and all of its nice [`futures::stream::StreamExt`]
//! helpers for watchers because we need lifetime-generic `Item` types. Effectively we're making
//! a lending stream. This is very close to lending iterators, which is one of the motivating
-//! examples for generic associated types (https://github.com/rust-lang/rust/issues/44265).
+//! examples for generic associated types (<https://github.com/rust-lang/rust/issues/44265>).
use std::{
fmt,
@@ -263,7 +263,7 @@
/// [`FnOnce`]). This would constraint the lifetime to `'static` and objects with `'event_loop`
/// returned by this runtime.
///
- /// Call [`spawn`] to respond to events. The non-event-driven APIs may be used without calling
+ /// Call [`EventLoopRuntime::spawn`] to respond to events. The non-event-driven APIs may be used without calling
/// this.
///
/// This is an async runtime, but it's a somewhat unusual one. See the module-level
@@ -313,7 +313,7 @@
/// same object from C++, which is a common operation. See the module-level documentation for
/// details.
///
- /// [`spawn`]ed tasks need to hold `&'event_loop` references to things like channels. Using a
+ /// spawned tasks need to hold `&'event_loop` references to things like channels. Using a
/// separate `'config` lifetime wouldn't change much; the tasks still need to do things which
/// require them to not outlive something they don't control. This is fundamental to
/// self-referential objects, which `aos::EventLoop` is based around, but Rust requires unsafe
@@ -396,7 +396,7 @@
/// will never complete. `task` will not be polled after the underlying `aos::EventLoop` exits.
///
/// Note that task will be polled immediately, to give it a chance to initialize. If you want to
- /// defer work until the event loop starts running, await [`on_run`] in the task.
+ /// defer work until the event loop starts running, await [`EventLoopRuntime::on_run`] in the task.
///
/// # Panics
///
@@ -775,7 +775,7 @@
///
/// We also run into some limitations in the borrow checker trying to implement `poll`, I think it's
/// the same one mentioned here:
-/// https://blog.rust-lang.org/2022/08/05/nll-by-default.html#looking-forward-what-can-we-expect-for-the-borrow-checker-of-the-future
+/// <https://blog.rust-lang.org/2022/08/05/nll-by-default.html#looking-forward-what-can-we-expect-for-the-borrow-checker-of-the-future>
/// We get around that one by moving the unbounded lifetime from the pointer dereference into the
/// function with the if statement.
// SAFETY: If this outlives the parent EventLoop, the C++ code will LOG(FATAL).
@@ -1197,7 +1197,7 @@
use ffi::aos::RawSender_Error as FfiError;
// SAFETY: This is a valid buffer we're passing.
- match unsafe { self.raw_sender.0.as_mut().SendBuffer(data.len()) } {
+ match self.raw_sender.0.as_mut().SendBuffer(data.len()) {
FfiError::kOk => Ok(()),
FfiError::kMessagesSentTooFast => Err(SendError::MessagesSentTooFast),
FfiError::kInvalidRedzone => Err(SendError::InvalidRedzone),
@@ -1496,8 +1496,8 @@
impl ExitHandle {
/// Exits the EventLoops represented by this handle. You probably want to immediately return
- /// from the context this is called in. Awaiting [`exit`] instead of using this function is an
- /// easy way to do that.
+ /// from the context this is called in. Awaiting [`ExitHandle::exit`] instead of using this
+ /// function is an easy way to do that.
pub fn exit_sync(mut self) {
self.0.as_mut().unwrap().Exit();
}
diff --git a/aos/events/ping_lib.rs b/aos/events/ping_lib.rs
index c4b3679..96d7132 100644
--- a/aos/events/ping_lib.rs
+++ b/aos/events/ping_lib.rs
@@ -20,6 +20,7 @@
}
/// Returns a future with all the tasks for the ping process
+ #[allow(unreachable_code)]
pub async fn tasks(&self, event_loop: EventLoopRuntime<'_>, sleep: u64) -> Never {
futures::join!(self.ping(&event_loop, sleep), self.handle_pong(&event_loop));
unreachable!("Let's hope `never_type` gets stabilized soon :)");
diff --git a/aos/events/simulated_event_loop.rs b/aos/events/simulated_event_loop.rs
index b453879..c75f34e 100644
--- a/aos/events/simulated_event_loop.rs
+++ b/aos/events/simulated_event_loop.rs
@@ -60,7 +60,7 @@
/// Creates a Rust-owned EventLoop.
///
/// You probably don't want to call this directly if you're creating a Rust application. This
- /// is intended for creating C++ applications. Use [`make_runtime`] instead when creating Rust
+ /// is intended for creating C++ applications. Use [`Self::make_runtime`] instead when creating Rust
/// applications.
pub fn make_event_loop(&mut self, name: &str, node: Option<&Node>) -> UniquePtr<CppEventLoop> {
// SAFETY:
@@ -77,7 +77,7 @@
}
}
- /// Creates an [`EventLoopRuntime`] wrapper which also owns its underlying [`EventLoop`].
+ /// Creates an [`EventLoopRuntime`] wrapper which also owns its underlying [`CppEventLoop`].
///
/// All setup must be performed with `fun`, which is called before this function returns. `fun`
/// may create further objects to use in async functions via [`EventLoop.spawn`] etc, but it is