Modernize the codebase

[markbt]

Putting this up as an RFC.

This updates to more modern code, including edition 2018. It now requires rustc 1.36 so that we can use things like AssumeUninit (without this, all the std::mem::uninitialized() calls show up as warnings).

Rust 1.36 was released over 6 months ago. However, it looks like Debian stable is pinned at 1.34, so if we want to keep targetting that as a minumum, we won't be able to take all of this. In practice I would expect users of Rust that are keeping their dependent crates up-to-date would also be using rustup to keep the compiler up-to-date, too.

Any comments?

[Alphare]

Mercurial uses rust-cpython extensively and targets Debian stable's version, I'm afraid this version bump breaks our compatibility guarantees. I would love to target 1.40+ for obvious reasons, but I'm afraid we are going to have to wait until Bullseye is released.

[Alphare]

Pinging @gracinet in case you have anything to add.

[markbt]

I thought that might be the case. I can drop the std::mem::MaybeUninit parts of the PR, as they are the ones that are not available in 1.34. That should let us still target 1.32+.

[Alphare]

@markbt You could play with config attributes to silence warnings depending on the version?
Thanks for being considerate of this matter.

[markbt]

Using cfg to target specific complier versions hasn't been stabilized yet (see rust-lang/rfcs#2523). Blanket #[allow(deprecated)] on the unsafe blocks that contain std::mem::uninitialized seems to work ok. I've left TODOs so we can clean up once bullseye is released.

I'll wait to see what @gracinet says, but hopefully this PR is now suitable for merging.

[gracinet]

@markbt yes we'll want to be able to build Mercurial Rust extensions on Debian buster, hence 1.34 and maybe even submit that for buster-backports, who knows? I'll take a closer look this evening if I can or maybe tomorrow.

[markbt]

I've switched to 1.32 now (which is the minimum version for edition 2018 and a couple of the associated syntax improvements). That should mean it works on stock Debian buster, although please do check.

I've suppressed the deprecation warnings for now. There's no real rush to replace std::mem::uninitialized() with std::mem::MaybeUninit.

[gracinet]

I've tested successfully with the Rust toolchain of Debian 10:

~ $ which cargo; which rustc; cargo --version; rustc --version
/usr/bin/cargo
/usr/bin/rustc
cargo 1.34.0
rustc 1.34.2
~ divers/rust-cpython $ git log --oneline -n1
a9e7e49 (HEAD, markbt/modernize) use paste to generate module init symbol names

and unsurprisingly have also been able to build Mercurial's hg-cpython

[gracinet]

Thanks for this, @markbt, switching to the 2018 edition will be a boon. And this unlocks the procedural macros

[gracinet]

I've read the whole diff quickly.

• switch to new use and reference to constructs from std or other crates
• explicit naming of arguments in traits
• removal of local_inner_macros, in favor of $crate:: and the associated local reexports of standard macros such as concat! (good riddance)
• thanks to the paste crate capability to concat identifiers, py_module_initializer! usage is vastly simplified, and the examples now reflect that (can't wait to apply this in the Mercurial code base)

[gracinet]

I think there's at least one fix in master (PR #206) that we'd maybe like to release first as a 0.4.1, and then this PR could bump the version number to 0.5.0, but maybe I'm overly conservative.

[markbt]

A 0.4.1 for #206 seems reasonable. I can spin that later this week unless you get there first, @gracinet.

[gracinet]

A 0.4.1 for #206 seems reasonable. I can spin that later this week unless you get there first, @gracinet.

Didn't realize I had the permissions to do that, but it makes sense. Trying right now, and should merge this PR afterwards.

[gracinet]

@markbt no, I can't publish directly on crates.io. Did all the other preparations, including the tag