summaryrefslogtreecommitdiffstats
path: root/src/tools/clippy/src/docs/default_numeric_fallback.txt
diff options
context:
space:
mode:
Diffstat (limited to 'src/tools/clippy/src/docs/default_numeric_fallback.txt')
-rw-r--r--src/tools/clippy/src/docs/default_numeric_fallback.txt28
1 files changed, 28 insertions, 0 deletions
diff --git a/src/tools/clippy/src/docs/default_numeric_fallback.txt b/src/tools/clippy/src/docs/default_numeric_fallback.txt
new file mode 100644
index 000000000..15076a0a6
--- /dev/null
+++ b/src/tools/clippy/src/docs/default_numeric_fallback.txt
@@ -0,0 +1,28 @@
+### What it does
+Checks for usage of unconstrained numeric literals which may cause default numeric fallback in type
+inference.
+
+Default numeric fallback means that if numeric types have not yet been bound to concrete
+types at the end of type inference, then integer type is bound to `i32`, and similarly
+floating type is bound to `f64`.
+
+See [RFC0212](https://github.com/rust-lang/rfcs/blob/master/text/0212-restore-int-fallback.md) for more information about the fallback.
+
+### Why is this bad?
+For those who are very careful about types, default numeric fallback
+can be a pitfall that cause unexpected runtime behavior.
+
+### Known problems
+This lint can only be allowed at the function level or above.
+
+### Example
+```
+let i = 10;
+let f = 1.23;
+```
+
+Use instead:
+```
+let i = 10i32;
+let f = 1.23f64;
+``` \ No newline at end of file