Fix typo.

Author: michaelwoerister

text/0000-symbol-name-mangling-v2.md

@@ -49,7 +49,7 @@ A symbol mangling scheme has a few goals, one of them essential, the rest of the
 
  - A mangled symbol should be *decodable* to some degree. That is, it is desirable to be able to tell which exact concrete instance of e.g. a polymorphic function a given symbol identifies. This is true for external tools, backtraces, or just people only having the binary representation of some piece of code available to them. With the current scheme, this kind of information gets lost in the magical hash-suffix.
 
- - It should be possible to predict the symbol name for a given source-level construct. For example, given the definition `fn foo<T>() { ... }`, the scheme should allow to construct, by hand, the symbol names for e.g. `foo<u32>` or `foo<extern fn(i32, &mut SomeStruct<(char, &str)>, ...) -> !>()`. Since the current scheme generates its hash from the values of various compiler internal data structures, not even an alternative compiler implementation could predicate the symbol name, even for simple cases.
+ - It should be possible to predict the symbol name for a given source-level construct. For example, given the definition `fn foo<T>() { ... }`, the scheme should allow to construct, by hand, the symbol names for e.g. `foo<u32>` or `foo<extern fn(i32, &mut SomeStruct<(char, &str)>, ...) -> !>()`. Since the current scheme generates its hash from the values of various compiler internal data structures, not even an alternative compiler implementation could predict the symbol name, even for simple cases.
 
  - A mangling scheme should be platform-independent. This is mainly achieved by restricting the character set to `A-Z`, `a-z`, `0-9`, `_`. All other characters might have special meaning in some context (e.g. `.` for MSVC `DEF` files) or are simply not supported (e.g. Unicode).