Update all references to my name

text/0089-loadable-lints.md

@@ -11,7 +11,7 @@ Allow users to load custom lints into `rustc`, similar to loadable syntax extens
 There are many possibilities for user-defined static checking:
 
 * Enforcing correct usage of Servo's [JS-managed pointers](https://github.com/mozilla/servo/blob/master/src/components/script/dom/bindings/js.rs)
-* kballard's use case: checking that `rust-lua` functions which call `longjmp` never have destructors on stack variables
+* lilyball's use case: checking that `rust-lua` functions which call `longjmp` never have destructors on stack variables
 * Enforcing a company or project style guide
 * Detecting common misuses of a library, e.g. expensive or non-idiomatic constructs
 * In cryptographic code, annotating which variables contain secrets and then forbidding their use in variable-time operations or memory addressing

text/0236-error-conventions.md

@@ -228,7 +228,7 @@ comment for more detail.
 There are numerous possible suffixes for a `Result`-producing variant:
 
 * `_catch`, as proposed above. As
-  [@kballard points out](https://github.com/rust-lang/rfcs/pull/236#issuecomment-55344336),
+  [@lilyball points out](https://github.com/rust-lang/rfcs/pull/236#issuecomment-55344336),
   this name connotes exception handling, which could be considered
   misleading. However, since it effectively prevents further unwinding, catching
   an exception may indeed be the right analogy.

text/0240-unsafe-api-location.md

@@ -88,7 +88,7 @@ and methods:
 
 The unsafe methods and static functions for a given type should be placed in
 their own `impl` block, at the end of the module defining the type; this will
-ensure that they are grouped together in rustdoc. (Thanks @kballard for the
+ensure that they are grouped together in rustdoc. (Thanks @lilyball for the
 suggestion.)
 
 # Drawbacks
@@ -125,7 +125,7 @@ There are a few alternatives:
   them `unsafe`), and given that rustdoc could easily provide API grouping, it's
   unclear exactly what the benefit is.
 
-* ([Suggested by @kballard](https://github.com/rust-lang/rfcs/pull/240#issuecomment-55635468)):
+* ([Suggested by @lilyball](https://github.com/rust-lang/rfcs/pull/240#issuecomment-55635468)):
 
   > Use `raw` for functions that construct a value of the type without checking
   > for one or more invariants.
@@ -140,7 +140,7 @@ There are a few alternatives:
   some_string.slice_unchecked(start, end)
   ```
 
-* Another suggestion by @kballard is to keep the basic structure of `raw`
+* Another suggestion by @lilyball is to keep the basic structure of `raw`
   submodules, but use associated types to improve the ergonomics. Details (and
   discussions of pros/cons) are in
   [this comment](https://github.com/rust-lang/rfcs/pull/240/files#r17572875).

text/2497-if-let-chains.md

@@ -1422,18 +1422,18 @@ Interestingly, the `EXPR is PAT` idea was floated in the original RFC 160 that
 introduced `if let` expressions in the first place. There, the notion that an
 operator named `is`, which introduces bindings, is confusing was brought up.
 
-[kballard_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48515260
-[kballard_2]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48551196
+[lilyball_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48515260
+[lilyball_2]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48551196
 [liigo_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49234092
-[kballard_3]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49242255
+[lilyball_3]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49242255
 
-It was also mentioned by [@kballard][kballard_1] that it would be appropriate
+It was also mentioned by [@lilyball][lilyball_1] that it would be appropriate
 if, and only if, it was limited to pattern matching, but not introducing any
 bindings. We make the same argument in this RFC. The issue of unintuitive
-scopes was also mentioned [by @kballard][kballard_2] there.
+scopes was also mentioned [by @lilyball][lilyball_2] there.
 
 Even the idea of `if EXPR match PAT` was floated by [@liigo][liigo_1] at the
-time but that idea was ultimately also rejected. [@kballard][kballard_3] opined
+time but that idea was ultimately also rejected. [@lilyball][lilyball_3] opined
 that using `match` as a binary operator would be *"very confusing"* but did not
 elaborate further at the time.