chore: Upgrade to 2021 edition

[LucioFranco]

No description provided.

[olix0r]

tioli, but you may want to update to new-style modules with:

:; for f in $(find . -name mod.rs) ; do git mv $f ${f%%/mod.rs}.rs ; done

[LucioFranco]

Is there something new about the new modules that wasn't there in 2018 edition?

[olix0r]

@LucioFranco now you can use foo.rs with foo/bar.rs instead of having to have foo/mod.rs -- I don't have a strong preference, but @hawkw suggested I do this when we moved to 2021 ;)

[danieleades]

Is there something new about the new modules that wasn't there in 2018 edition?

nope. this was introduced in 2018.

it's pretty nice though. prevents the situation where you have 6 files open in your editor all called mod...

[LucioFranco]

Oh okay its not something new xD for some reason I still like mod.rs but we can move tonic/other tokio libs over Im not against it.

[hawkw]

@LucioFranco now you can use foo.rs with foo/bar.rs instead of having to have foo/mod.rs -- I don't have a strong preference, but @hawkw suggested I do this when we moved to 2021 ;)

Yeah, this is a Rust 2018 feature; i just left a comment about it when we were doing the upgrade because it seemed like a good thing to do.

Oh okay its not something new xD for some reason I still like mod.rs but we can move tonic/other tokio libs over Im not against it.

I agree that mod.rs is more conceptually appealing to me, since the main code for the module is still inside the module directory, which feels right to me.

However, there's one significant practical advantage for Rust 2018-style modules:
in the new style modules, the module goes in a file named <module_name>.rs even if it has submodules in separate files, and they go in <module_name>/<submodule>.rs, rather than having to move the module to <module_name>/mod.rs when adding submodules. This means that if you have a module that's currently in a single file, and you want to add new submodules to it as separate files, you don't have to move all the code in the existing file into a new location, which confuses GitHub's diff viewer --- all that code will show up as "added", even though it was all there before, which is confusing when some of the code in the module also changed as part of a PR --- you can't immediately tell what actually changed, and what was "added" because of moving the file to the new location. e. This might make commits that add submodules less painful to review.

Not saying that Tonic has to switch, but we might want to consider it for that reason.

[hawkw]

It's not at all related to the Rust 2021 edition, though --- I just happened to think of it when we were updating Linkerd to Rust 2021, because it's also an edition-related change, even though it's from a prior edition. :)

[LucioFranco]

Yeah, personally im not convinced either way but if we do move we should do all of tokio projects at once lol

[Thomasdezeeuw]

Just wanted to note that prevents people from updating to v0.6 who don't have a 5 day old compiler for (seemingly) very little gain... I know tonic doesn't provide any stability guarantees (yet), but I mean merging this the day after the stable compiler release is a bit quick isn't it?

In the future please give people at least 1 or 2 compiler releases before updating the edition.

[davidpdrsn]

Given that 0.6 was a breaking release and tonic doesn't specify an MSRV, I think updating to the 2021 edition like this was totally fine.

Whether tonic should have specify an MSRV is a different discussion though.

[Thomasdezeeuw]

Given that 0.6 was a breaking release and tonic doesn't specify an MSRV, I think updating to the 2021 edition like this was totally fine.

I'm not saying you should or shouldn't specify an MSRV, but having a (implicit) MSRV that is barely a day old is not really user friendly, that's all I wanted to note.

Whether tonic should have specify an MSRV is a different discussion though.

[LucioFranco]

@Thomasdezeeuw very valid point, if we have someone who is blocked on this we can yank 0.6 and 0.6.1 and put out a 0.6.2 w/ 2018. I am not opposed I didn't really think that 2021 would be that big of an issue but I am realizing now it probably is.

[danieleades]

Not sure I see how it's an issue? The people impacted will be those that require a feature or bug fix which is in tonic 0.6 but not in 0.5, but who also cannot use the latest stable compiler. How big an overlap is there in that Venn diagram? What constraints are putting people in that very specific position?

(Though I do agree an MSRV is a good idea. But even then you are allowed to bump it up on a new release with notice, modulo whatever policy you adopt)