FileExt methods cause compiler warnings on rust 1.84

[eric-seppanen]

Using the lock methods from fs2 cause rustc warnings on rust 1.84:

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
}

warning: a method with this name may be added to the standard library in the future
 --> src/lib.rs:8:10
  |
8 |     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.

[danburkert]

It seems like the lint is faulty, the linked rust issue contains similar complaints. Regardless, there’s not much to be done on the fs2 side, other than rename the methods but I don’t think that’s a good idea. If you want to avoid the lint you can use fully qualified syntax or suppress it, as rustc suggests.

…

On Wed, Nov 27, 2024 at 11:48 AM Eric Seppanen ***@***.***> wrote: Using the lock methods from fs2 cause rustc warnings on rust 1.83: 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} warning: a method with this name may be added to the standard library in the future --> src/lib.rs:8:10 | 8 | 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 <rust-lang/rust#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. — Reply to this email directly, view it on GitHub <#50>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHD4UZK64P72M5JHK6KT32CYOZVAVCNFSM6AAAAABSTTHOI2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGY4TSNRVGY2TMOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[eric-seppanen]

It may be annoying but the lint is correct: if the file_lock feature gets stabilized, code that was calling the fs2 methods will silently switch over to the std methods instead.

[Kobzol]

Note that the standard library API has changed in the end (rust-lang/rust#142125), and it was stabilized. Which means that code that was using these methods from fs2 will not only switch to the stdlib methods, but it will outright fail to compile in many cases.