use 2018 edition idioms

[danieleades]

this refactors the crate to use 2018 edition idioms

• explicit macro imports
• 2018-style modules
• apply formatting (cargo +nightly fmt)

[danieleades]

this would add 2018 edition idioms just in time for the 2021 edition...

the only place this is likely to bite even slightly is the 'extern crate' macro imports. there's a decent chance this style of import will become a compiler warning in 2021 edition (see rust-lang/rust#80165). Not a hard error, mind.

Although keeping the 2015 idioms isn't actually going to cause any real problems, i'm inclined to believe the 2018 idioms were introduced for good reasons.

• i'm a big fan of explicit macro imports. i think implicit global imports are a bit 'magic', and it's weird that they're treated differently to every other first-class object
• the 2018-style module structure is a big win if you've ever had multiple mod.rs files open in an IDE at once. I find that the file paths are less ambiguous, and i'm immediately more 'context-aware' working on code. Makes me less likely to 'stutter' in the fully-qualified name of an object (ie. recovery::version::RecoveryVersionError, which could just as easily be recovery::version::Error)

[danieleades]

rebased on master

[crawfxrd]

The commit dropping the cli2 directory should be applied as a fixup to the commit that introduced it.

I think the explicit imports should be collapsed into one commit, since they're doing the same thing.

[danieleades]

The commit dropping the cli2 directory should be applied as a fixup to the commit that introduced it.

I think the explicit imports should be collapsed into one commit, since they're doing the same thing.

I had assumed this would all be applied as a single squash merge

[crawfxrd]

The repo appears to be configured for squash merging by default (don't know why), but the preferred method is rebase merging.

[danieleades]

The repo appears to be configured for squash merging by default (don't know why), but the preferred method is rebase merging.

i'm tempted to rebase this as a single commit (which is a squash merge) unless you particularly want these commits separated?

[crawfxrd]

I think how you did it in system76-power is good. One commit for moving files for 2018-style crates, and one commit for explicit imports. There's some rustfmt changes mixed in, which could also be a separate commit (or remove them and leave it for #155).

[danieleades]

i've rebased and tidied the commits.

i've left the formatting, for the simple reason that it would be painful to change. #155 can prevent this kind of noise happening again. Don't really mind which gets merged first, i can rebase either pull request on the other without too much pain.

[bflanagin]

No regressions found.