Using the lock methods from fs_std cause rustc warnings on rust 1.84:
use fs4::fs_std::FileExt;
pub fn read_file(filename: &str) -> String {
let mut file = std::fs::File::open(filename).unwrap();
file.lock_shared().unwrap();
let mut data = String::new();
file.read_to_string(&mut data).unwrap();
data
}
$ cargo +beta-2024-11-27 check
warning: a method with this name may be added to the standard library in the future
--> src/lib.rs:10:10
|
10 | file.lock_shared().unwrap();
| ^^^^^^^^^^^
|
= warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
= note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
= help: call with fully qualified syntax `lock_shared(...)` to keep using the current method
= note: `#[warn(unstable_name_collisions)]` on by default
The name collision happens for lock_shared, try_lock_shared, and unlock, which are tracked by the file_lock feature (rust-lang/rust#130994).
Using the lock methods from
fs_stdcause rustc warnings on rust 1.84:The name collision happens for
lock_shared,try_lock_shared, andunlock, which are tracked by thefile_lockfeature (rust-lang/rust#130994).