From 2762ec5800d94e7891c7b01f39f57c0b79eb3088 Mon Sep 17 00:00:00 2001
From: dignifiedquire <me@dignifiedquire.com>
Date: Sat, 9 May 2020 11:36:13 +0200
Subject: [PATCH] fix(fs): use smol::block_on for drop handling of File

Ref #766
---
 src/fs/file.rs | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/fs/file.rs b/src/fs/file.rs
index 7fe99ee4..74d2bfde 100644
--- a/src/fs/file.rs
+++ b/src/fs/file.rs
@@ -12,7 +12,7 @@ use crate::future;
 use crate::io::{self, Read, Seek, SeekFrom, Write};
 use crate::path::Path;
 use crate::prelude::*;
-use crate::task::{self, spawn_blocking, Context, Poll, Waker};
+use crate::task::{spawn_blocking, Context, Poll, Waker};
 use crate::utils::Context as _;
 
 /// An open file on the filesystem.
@@ -315,7 +315,7 @@ impl Drop for File {
         // non-blocking fashion, but our only other option here is losing data remaining in the
         // write cache. Good task schedulers should be resilient to occasional blocking hiccups in
         // file destructors so we don't expect this to be a common problem in practice.
-        let _ = task::block_on(self.flush());
+        let _ = smol::block_on(self.flush());
     }
 }
 
@@ -867,3 +867,15 @@ impl LockGuard<State> {
         Poll::Ready(Ok(()))
     }
 }
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn async_file_drop() {
+        crate::task::block_on(async move {
+            File::open(".").await.unwrap();
+        });
+    }
+}