summaryrefslogtreecommitdiffstats
path: root/src/tools/clippy/src/docs/await_holding_invalid_type.txt
diff options
context:
space:
mode:
Diffstat (limited to 'src/tools/clippy/src/docs/await_holding_invalid_type.txt')
-rw-r--r--src/tools/clippy/src/docs/await_holding_invalid_type.txt29
1 files changed, 29 insertions, 0 deletions
diff --git a/src/tools/clippy/src/docs/await_holding_invalid_type.txt b/src/tools/clippy/src/docs/await_holding_invalid_type.txt
new file mode 100644
index 000000000..e9c768772
--- /dev/null
+++ b/src/tools/clippy/src/docs/await_holding_invalid_type.txt
@@ -0,0 +1,29 @@
+### What it does
+Allows users to configure types which should not be held across `await`
+suspension points.
+
+### Why is this bad?
+There are some types which are perfectly "safe" to be used concurrently
+from a memory access perspective but will cause bugs at runtime if they
+are held in such a way.
+
+### Example
+
+```
+await-holding-invalid-types = [
+ # You can specify a type name
+ "CustomLockType",
+ # You can (optionally) specify a reason
+ { path = "OtherCustomLockType", reason = "Relies on a thread local" }
+]
+```
+
+```
+struct CustomLockType;
+struct OtherCustomLockType;
+async fn foo() {
+ let _x = CustomLockType;
+ let _y = OtherCustomLockType;
+ baz().await; // Lint violation
+}
+``` \ No newline at end of file