Enable workspace lints

[kennykerr]

As suggested in #2739, I'm enabling workspace lints to more easily enable non-default Rust and Clippy lints.

I've started with only elided-lifetimes-in-paths as some of the others, like rust_2018_idioms, has some false positives that prevent them from being turned on for this workspace.

Fixes: #2739

[ChrisDenton]

If it's only a single case, would adding an #[allow(unused_extern_crates)] // false positive be worth it so you still get everything else linted?

[kennykerr]

Seems to work!

[ChrisDenton]

Is the reason for the false positive that CI doesn't always use features that use it? E.g. clippy is run with no features at all

windows-rs/.github/workflows/clippy.yml

Line 146 in 831b99b

cargo clippy -p windows-sys &&

[ChrisDenton]

In any case, this PR lgtm.

[kennykerr]

Is the reason for the false positive that CI doesn't always use features that use it? E.g. clippy is run with no features at all

windows-rs/.github/workflows/clippy.yml

Line 146 in 831b99b

cargo clippy -p windows-sys &&

Yes, it isn't used in all cases. It is used by some features and by the optional implement and interface macros.

[MarijnS95]

It does not seem that this is needed for anything; the lint is valid. There is nothing inside sys / windows referring to (::)windows_sys:: or (::)windows:: respectively. Could these lines just be removed altogether?

[MarijnS95]

Err, I meant to say that:

1. On windows_sys I don't seem to get a false-positive here, because it's actually used;
2. On windows I only get a few errors originating from the windows_implement macro, which expects the windows crate to be available as an external crate (which is interesting for a macro that generates code to be used both inside and outside of a crate).
   EDIT: It's actually including ::windows::core::. Wasn't there a request before to use ::windows_core:: here so that the macro can also be used without the windows crate (at the downside that windows+implement users now need both crates)?

[ChrisDenton]

> cargo clippy -p windows-sys
    Checking windows-sys v0.52.0 (R:\windows-rs\crates\libs\sys)
warning: unused extern crate
  --> crates\libs\sys\src\lib.rs:11:1
   |
11 | extern crate self as windows_sys;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
   |
   = note: `-W unused-extern-crates` implied by `-W rust-2018-idioms`
   = help: to override `-W rust-2018-idioms` add `#[allow(unused_extern_crates)]`

warning: `windows-sys` (lib) generated 1 warning (run `cargo clippy --fix --lib -p windows-sys` to apply 1 suggestion)
    Finished dev [unoptimized + debuginfo] target(s) in 2m 49s

> cargo clippy -p windows-sys --features Win32
    Checking windows-sys v0.52.0 (R:\windows-rs\crates\libs\sys)
    Finished dev [unoptimized + debuginfo] target(s) in 1.41s

[MarijnS95]

See the console highlight:

> cargo clippy -p windows-sys
    Checking windows-sys v0.52.0 (R:\windows-rs\crates\libs\sys)
warning: unused extern crate
  --> crates\libs\sys\src\lib.rs:11:1
   |
11 | extern crate self as windows_sys;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it
   |
   = note: `-W unused-extern-crates` implied by `-W rust-2018-idioms`
   = help: to override `-W rust-2018-idioms` add `#[allow(unused_extern_crates)]`

warning: `windows-sys` (lib) generated 1 warning (run `cargo clippy --fix --lib -p windows-sys` to apply 1 suggestion)
    Finished dev [unoptimized + debuginfo] target(s) in 2m 49s

> cargo clippy -p windows-sys --features Win32
    Checking windows-sys v0.52.0 (R:\windows-rs\crates\libs\sys)
    Finished dev [unoptimized + debuginfo] target(s) in 1.41s

Indeed, it is conditionally used :(

[kennykerr]

On windows I only get a few errors originating from the windows_implement macro, which expects the windows crate to be available as an external crate (which is interesting for a macro that generates code to be used both inside and outside of a crate).
EDIT: It's actually including ::windows::core::. Wasn't there a request before to use ::windows_core:: here so that the macro can also be used without the windows crate (at the downside that windows+implement users now need both crates)?

If there's a simpler solution, I'd love to hear it. I'd like to make the macros depend only on the windows_core crate but that makes it less convenient for what I'd consider is the majority of developers.

[MarijnS95]

If there's a simpler solution, I'd love to hear it. I'd like to make the macros depend only on the windows_core crate but that makes it less convenient for what I'd consider is the majority of developers.

Those two desires conflict, unfortunately. We can either use ::windows_core:: import and drop the extern crate self as windows, which makes the macros depend on only windows_core. Or leave it for what it is.

There is a special crate that is able to process renames in Cargo.toml (https://crates.io/crates/proc-macro-crate), maybe such a technique can be used to understand whether windows, windows_core, or both (and if so, what they might have been renamed to!) are part of the current crate dependency, and switch between ::windows::core and ::windows_core:: based on that?