Comments on use statements incorrectly rearranged when use statements are rearranged

[bddap]

Input:

use c; // use c;
use b; // use b;
use a; // use a;

Expected:

use a; // use a;
use b; // use b;
use c; // use c;

Got:

use a;
use b; // use b;
use c; // use c; // use a;

rustc 1.36.0 (a53f9df32 2019-07-03)
binary: rustc
commit-hash: a53f9df32fbb0b5f4382caaad8f1a46f36ea887c
commit-date: 2019-07-03
host: x86_64-apple-darwin
release: 1.36.0
LLVM version: 8.0

[mbarbar]

I will add that this also has some issues with leading comments. The problem can be reproduced with two uses, but I think the issue becomes clearer with 3 (like your example):

/*cpre*/ use c; // cpost
/*bpre*/ use b; // bpost
/*apre*/ use a; // apost

produces

/*cpre*/
/*apre*/ use a;
/*bpre*/ use b; // bpost
use c; // cpost // apost

The problem seems to be in src/reorder.rs's walk_reorderable_items (or in rewrite_reorderable_items, depending on how you look at it). The span variable created does not include the first leading comment or the final trailing comment. It's kind of like a fence-post error. When we're reordering, cpre doesn't "belong" to use c and apost doesn't "belong" to use a because searching for comments is limited by the span.

Simply extending the span to the end of the previous item and start of the next item I believe would fail because then the first and last item would "steal" comments belonging to other items. I'll take a better look when I have more time. I think it can be solved by very explicitly including the first pre- and last post-comments to span by searching for the comments before we even get to rewrite_reorderable_items.

[dhardy]

I think this is the same bug:

// original
use crate::text::TextApi;
// for doc use
#[allow(unused)]
use crate::text::TextApiExt;
use crate::macros::autoimpl;

// ——— rustfmt output ———
use crate::text::TextApi;
// for doc use
use crate::macros::autoimpl;
#[allow(unused)]
use crate::text::TextApiExt;

[ytmimi]

related to #3127

[RalfJung]

#5485 is an example of this that I almost missed, where this meant a pretty fundamental change in the semantics of the comment.

Is there a tag for "rustfmt does something to the source code that changes its meaning for human readers" (aka 'pretty critical')?