Fix Engrish

src/lib.rs

@@ -1,7 +1,7 @@
 //! This allocator be straight up *slabbin'*.
 //!
 //! A slab allocator is in theory the perfect one, if it's applicable. It's blazingly fast and
-//! avoids the issue of external fragmentation; but unlike the bump allocator it can free
+//! avoids the issue of external fragmentation, but unlike the bump allocator it can free
 //! individual allocations, and unlike the stack allocator it can free them in an arbitrary order.
 //! The tradeoff here is that all allocations must have the same, fixed layout.
 //!
@@ -147,9 +147,9 @@ pub struct SlabAllocator<T> {
     slab_capacity: NonZeroUsize,
 }
 
-// SAFETY: The pointers we hold are not referencing the stack or TLS or anything like that, they
+// SAFETY: The pointers we hold are not referencing the stack or TLS or anything like that; they
 // are all heap allocations, and therefore sending them to another thread is safe. Note that it is
-// safe to do this regardless of whether `T` is `Send`: the allocator itself doesn't own any `T`s,
+// safe to do this regardless of whether `T` is `Send`: the allocator itself doesn't own any `T`s;
 // the user does and manages their lifetime explicitly by allocating, initializing, deinitializing
 // and then deallocating them. It is therefore their responsibility that a type that is `!Send`
 // doesn't escape the thread it was created on (just like with any other allocator, it just so