Make gix crates ready for automatic cfg checking

[Urgau]

This PR makes the necessary changes to make gitoxide crates ready for -Zcheck-cfg (automatic cfgs checking) being enabled by default.

• It first removes all the --cfg docsrs and #[cfg_attr(docsrs, ...)] which are an anti-pattern and simply use the already existing feature document-features.
• It also add a missing serde feature in gix-fs and remove a dead code from the now non-existing lean-cli feature.
• I also added the async-io feature to gix-packetline-blocking since being a symlink to gix-packetline it needs to have all the feature of the former.
  Maybe instead of adding the async-io feature we could allow the lint for gix-packetline-blocking?
• And finally it adds a new CI job lint-nightly to run nightly tools, in particular cargo check -Zcheck-cfg.

[Urgau]

The CI failures are related to some new clippy lints and the nightly feature activation being now tied to an actual feature making them fail with --all-features.

Let me know how you want to proceed?
One "hack" I see could be to only make the nightly feature activation on when documenting, ie doc cfg.

[Byron]

Thanks a lot for contributing the preparation for the upcoming check-cfg feature 🙏🎉!

• I also added the async-io feature to gix-packetline-blocking since being a symlink to gix-packetline it needs to have all the feature of the former.
  Maybe instead of adding the async-io feature we could allow the lint for gix-packetline-blocking?

This whole crate is a hack, unfortunately, so that there is a blocking version of the crate that can be used internally, without having the overhead of a real copy. Thus, I don't think one should add anything else to it - it fulfils its purpose and ideally won't be used. I hope that once there are new async-related features, it can be removed entirely. Or in other words, gitoxide currently has a couple of non-additive feature-flags around async-support and this will be a problem for all the usual reason. It desperately needs to be made so sync and async can both be managed without duplicating everything, and we are not there yet.

• And finally it adds a new CI job lint-nightly to run nightly tools, in particular cargo check -Zcheck-cfg.

It's a very nice gesture, but I think if it should be useful it needs to be made so it can't actually fail a build. Ideally, it provides a preview of what's to come, but I can't have failures on a daily basis because new lint was added. Right now, I see this every 6 weeks or so when a new stable release trickles down, and that seems good enough.

One "hack" I see could be to only make the nightly feature activation on when documenting, ie doc cfg.

Everything you think would work also works for me. There is just this one requirement that docs.rs still needs to be able to build these crates,

[Urgau]

Regarding the changes to gix-packetline-blocking. Should I remove them? They currently result in 20ish warnings.

• And finally it adds a new CI job lint-nightly to run nightly tools, in particular cargo check -Zcheck-cfg.

It's a very nice gesture, but I think if it should be useful it needs to be made so it can't actually fail a build. Ideally, it provides a preview of what's to come, but I can't have failures on a daily basis because new lint was added. Right now, I see this every 6 weeks or so when a new stable release trickles down, and that seems good enough.

Completely agree, it's unreasonable to expect someone to block on nightly. My idea is to run the job as normal but to mark it as not failling, that's why I added continue-on-error: true to the job so that it doesn't fail but that didn't work out.

Changed to if: '!cancelled() to always run every steps. Seems now I need a way to not mark it as failing the whole workflow.

One "hack" I see could be to only make the nightly feature activation on when documenting, ie doc cfg.

Everything you think would work also works for me. There is just this one requirement that docs.rs still needs to be able to build these crates,

Seems to work and it-fact it was even used before, so.

[Byron]

Completely agree, it's unreasonable to expect someone to block on nightly. My idea is to run the job as normal but to mark it as not failling, that's why I added continue-on-error: true to the job so that it doesn't fail but that didn't work out.

Changed to if: '!cancelled() to always run every steps. Seems now I need a way to not mark it as failing the whole workflow.

Let's remove nightly, it's clean and will definitely work. It's also only tangentially related to this PR, so I think it's the right thing to do.

I will probably just do that myself before merging, so nothing left to be done here.

Thanks again for your help, it's much appreciated!

[Byron]

A great catch, thank you!

[epage]

It first removes all the --cfg docsrs and #[cfg_attr(docsrs, ...)] which are an anti-pattern and simply use the already existing feature document-features.

According to whom is it an anti-pattern? I've not seen any talk of that and found it much better than using features.

[Urgau]

It first removes all the --cfg docsrs and #[cfg_attr(docsrs, ...)] which are an anti-pattern and simply use the already existing feature document-features.

According to whom is it an anti-pattern? I've not seen any talk of that and found it much better than using features.

I meant that with check-cfg+Cargo it's a bit of "anti-pattern" since enabling the docsrs cfg (or any custom cfg) is not free and easy, since it requires a build.rs with cargo:rustc-check-cfg.

[epage]

Its not sufficient with build.rs because that will produce the warning as well.

I wouldn't classify that as an anti-pattern but a relevant use case for us to consider.