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.