Fix some mistakes in the documentation (#314)

docs/_pages/compatibility.md

@@ -116,7 +116,7 @@ Floor division is less harmful, but it's used rarely enough that `math.floor(a/b
 | The function print calls `__tostring` instead of tostring to format its arguments. | ✔️ | |
 | By default, the decoding functions in the utf8 library do not accept surrogates. | 😞 | breaks compatibility and doesn't seem very interesting otherwise |
 
-Lua has a beautiful syntax and frankly we're disappointed in the `<const>`/`<toclose>` which takes away from that beauty. Taking syntax aside, `<toclose>` isn't very useful in Luau - its dominant use case is for code that works with external resources like files or sockets, but we don't provide such APIs - and has a very large complexity cost, evidences by a lot of bug fixes since the initial implementation in 5.4 work versions. `<const>` in Luau doesn't matter for performance - our multi-pass compiler is already able to analyze the usage of the variable to know if it's modified or not and extract all performance gains from it - so the only use here is for code readability, where the `<const>` syntax is... suboptimal.
+Lua has a beautiful syntax and frankly we're disappointed in the `<const>`/`<close>` which takes away from that beauty. Taking syntax aside, `<close>` isn't very useful in Luau - its dominant use case is for code that works with external resources like files or sockets, but we don't provide such APIs - and has a very large complexity cost, evidences by a lot of bug fixes since the initial implementation in 5.4 work versions. `<const>` in Luau doesn't matter for performance - our multi-pass compiler is already able to analyze the usage of the variable to know if it's modified or not and extract all performance gains from it - so the only use here is for code readability, where the `<const>` syntax is... suboptimal.
 
 If we do end up introducing const variables, it would be through a `const var = value` syntax, which is backwards compatible through a context-sensitive keyword similar to `type`.
 

docs/_pages/lint.md

@@ -145,7 +145,7 @@ In some cases the linter can detect code that is never executed, because all exe
 ```lua
 function cbrt(v)
     if v >= 0 then
-        return v ^ 1/3
+        return v ^ (1/3)
     else
         error('cbrt expects a non-negative argument')
     end

docs/_pages/syntax.md

@@ -27,7 +27,7 @@ The rest of this document documents additional syntax used in Luau.
 
 ## String literals
 
-Luau implements support for hexadecimal (`\0x`), Unicode (`\u`) and `\z` escapes for string literals. This syntax follows [Lua 5.3 syntax](https://www.lua.org/manual/5.3/manual.html#3.1):
+Luau implements support for hexadecimal (`\x`), Unicode (`\u`) and `\z` escapes for string literals. This syntax follows [Lua 5.3 syntax](https://www.lua.org/manual/5.3/manual.html#3.1):
 
 - `\xAB` inserts a character with the code 0xAB into the string
 - `\u{ABC}` inserts a UTF8 byte sequence that encodes U+0ABC character into the string (note that braces are mandatory)
@@ -158,7 +158,7 @@ In addition to declaring types for a given value, Luau supports declaring type a
 ```lua
 type Point = { x: number, y: number }
 type Array<T> = { [number]: T }
-type Something = typeof(string.gmatch("", "\d"))
+type Something = typeof(string.gmatch("", "%d"))
 ```
 
 The right hand side of the type alias can be a type definition or a `typeof` expression; `typeof` expression doesn't evaluate its argument at runtime.