Resolve: stop requiring `use` and `extern crate` declarations to precede statements in blocks

[jseyfried]

We no longer require use and extern crate items to precede other items in modules thanks to RFC #385, but we still require use and extern crate items to precede statements in blocks (other items can appear anywhere in a block).

I think that this is a needless distinction between imports and other items that contradicts the intent of the RFC.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[nagisa]

I personally think that lifting the restriction in question could only result in worse code. Perhaps we should downgrade it to a warning-by-default lint?

[jseyfried]

@nagisa
Do you think it is ever a good idea to have a module, struct, or enum follow a statement?

If so, I think this example (for modules, also applies to enums) and this example (for structs) from the RFC motivate allowing use items as well.

If not, I think we should not permit any item to follow a statement (or at least make it a warning/lint). I would be OK with this, but I don't see any reason to only permit a certain class of item like we are doing now.

[alexcrichton]

r? @nrc

cc @rust-lang/lang

[huonw]

I feel like this would allow something like

fn foo() {}

fn bar() {
    foo();
    use qux::foo;
    foo();
}

which would presumably be calling qux::foo twice, but doesn't look like it. This isn't such a problem with normal items because there's no layered scoping like this (i.e. you don't inherit items in scope from a parent inside a mod, everything has to be imported/declared explicitly), and we disallow repeated definitions of a name inside a single scope.

[jseyfried]

@huonw I agree that your example is problematic, but we currently allow

fn foo() {}
fn bar() {
    foo(); // Prints "foo!"
    fn foo() { println!("foo!"); }
    foo(); // Prints "foo!"
}

which I think is problematic for exactly the same reason.
I don't see why we would allow my example but not yours.

[huonw]

I don't think something confusing existing already is a good justification for adding more confusing things. :) Don't get me wrong though: uniformity is a good reason.

[petrochenkov]

+1 to this PR, item scoping in blocks may already be surprising and needs to be explained well, and random exceptions don't make things easier to explain.

[oli-obk]

clippy now has an items_after_statements lint that does these checks, except if a macro expands to an item.

[nrc]

@bors: r+

[bors]

📌 Commit f05bc16 has been approved by nrc

[bors]

⌛️ Testing commit f05bc16 with merge f030d1f...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt