Fix misspellings in comments (#1618)

src/lib.rs

@@ -28,7 +28,7 @@
 //! Some user activity, like mouse movement, can generate both a [`WindowEvent`] *and* a
 //! [`DeviceEvent`]. You can also create and handle your own custom [`UserEvent`]s, if desired.
 //!
-//! You can retreive events by calling [`EventLoop::run`][event_loop_run]. This function will
+//! You can retrieve events by calling [`EventLoop::run`][event_loop_run]. This function will
 //! dispatch events for every [`Window`] that was created with that particular [`EventLoop`], and
 //! will run until the `control_flow` argument given to the closure is set to
 //! [`ControlFlow`]`::`[`Exit`], at which point [`Event`]`::`[`LoopDestroyed`] is emitted and the

src/monitor.rs

@@ -1,7 +1,7 @@
 //! Types useful for interacting with a user's monitors.
 //!
 //! If you want to get basic information about a monitor, you can use the [`MonitorHandle`][monitor_handle]
-//! type. This is retreived from one of the following methods, which return an iterator of
+//! type. This is retrieved from one of the following methods, which return an iterator of
 //! [`MonitorHandle`][monitor_handle]:
 //! - [`EventLoopWindowTarget::available_monitors`][loop_get]
 //! - [`Window::available_monitors`][window_get].

src/platform_impl/linux/x11/window.rs

@@ -227,7 +227,7 @@ impl UnownedWindow {
                 // is > 0, like we do in glutin.
                 //
                 // It is non obvious which masks, if any, we should pass to
-                // `XGetVisualInfo`. winit doesn't recieve any info about what
+                // `XGetVisualInfo`. winit doesn't receive any info about what
                 // properties the user wants. Users should consider choosing the
                 // visual themselves as glutin does.
                 match pl_attribs.visual_infos {