-//@ Now, imagine what would happen if we were permitted to also mutate `var`. We could, for example,
-//@ make it a `Text`. However, `ptr` still points to the old location! Hence `ptr` now points somewhere
-//@ into the representation of a `String`. By changing `ptr`, we manipulate the string in completely
-//@ unpredictable ways, and anything could happen if we were to use it again! (Technically, the first field
-//@ of a `String` is a pointer to its character data, so by overwriting that pointer with an integer,
-//@ we make it a completely invalid address. When the destructor of `var` runs, it would try to deallocate
-//@ that address, and Rust would eat your laundry - or whatever.)
-//@
-//@ I hope this example clarifies why Rust has to rule out mutation in the presence of aliasing *in general*,
-//@ not just for the specific case of a buffer being reallocated, and old pointers becoming hence invalid.
+//@ Now, imagine what would happen if we were permitted to also mutate `var`. We could, for
+//@ example, make it a `Text`. However, `ptr` still points to the old location! Hence `ptr` now
+//@ points somewhere into the representation of a `String`. By changing `ptr`, we manipulate the
+//@ string in completely unpredictable ways, and anything could happen if we were to use it again!
+//@ (Technically, the first field of a `String` is a pointer to its character data, so by
+//@ overwriting that pointer with an integer, we make it a completely invalid address. When the
+//@ destructor of `var` runs, it would try to deallocate that address, and Rust would eat your
+//@ laundry - or whatever.) I hope this example clarifies why Rust has to rule out mutation in the
+//@ presence of aliasing *in general*, not just for the specific case of a buffer being
+//@ reallocated, and old pointers becoming hence invalid.