reflow

[drahnr]

What does this PR accomplish?

Pushing #72 over the 🏁

• 🦚 Feature

Closes #39

Changes proposed by this PR:

Remaining Challenges

• a span is not a 1:1 mapping of a line
• user selection must work with multiline suggestions (related to / covered by reflow #95 )
• provide the same logic of --code exit code flags like we do for check
• assure test cases cover all variant types with all possible single/multiline variations

Notes to reviewer:

📜 Checklist

• Works on the ./demo sub directory
• Test coverage is excellent and passes
• Documentation is thorough

[drahnr]

Looks pretty well, I have yet to test this, a few nits as per usual 🛩️

[drahnr]

The assumption that there is one span per line is incorrect though.

Counter example:

#[doc=r#"yada
yada
"#]

[drahnr]

Added initial hooks for args and forwarding all of that, there are still a few 🚧 areas which need resolving.

Checklist moved to initial PR comment.

[KuabeM]

Regarding the Span to line mapping: We can't really do something about that, the only (hacky) workaround I can think of is to count the number of whitespaces on multiline spans. In other words, use span.start for the first line of the span and we have to count the whitespaces for all subsequent lines.

[drahnr]

Not sure I understand your last comment. Do you mean newlines I stead of spaces? Not sure how that will help us here?

I think for doc=#r" comments we would be able to reflow, for doc=" the newlines would need to be escaped but any indent after the first would either be identical or set to 0.

[drahnr]

The reflow check here is correct, but we could never use this as a direct replacement, since it would cover additional lines.
We would need a injection suggestion with a source span length of 0 (so nothing is removed, only text is inserted at that position). If this is the case, the comment type (/// in this case ) needs to be added as a injection for any additional lines inserted.

Semantically a "change" (to disambiguate) might have multiple spans it's going to cover, where a suggestion is only for one particular span - that's how it's modelled right now. I would stick with that, since all the selection code depends on that iirc - semantically it would make sense to move suggestions into multispan handling and span -> replacement based map.

[drahnr]

Another rebase round to get CI going.

[drahnr]

Progress! 🚂

There is still one assertion that fails, but you are getting closer!

> cargo run -- reflow --code 27 -r demo/src/

    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/cargo-spellcheck reflow --code 27 -r demo/src/`
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: TripleSlash vs DoubleSlashEM
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: MacroDocEq vs TripleSlash
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: TripleSlash vs MacroDocEq
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: MacroDocEq vs TripleSlash
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: TripleSlash vs MacroDocEq
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: TripleSlash vs DoubleSlashEM
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: TripleSlash vs DoubleSlashEM
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: MacroDocEq vs TripleSlash
[2020-10-07T07:15:31Z ERROR cargo_spellcheck::documentation::literalset] Adjacent literal is not the same comment variant: TripleSlash vs MacroDocEq
error: spellcheck(Reflow)
   --> /media/supersonic1t/projects/cargo-spellcheck/demo/src/nested/mod.rs:11
    |
 11 |  Overly long statements that should be reflown since they are __very__ long and exceed the line limit.
    |  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(1/6) Apply this suggestion [y,n,q,a,d,j,e,?]?

 »  Overly long statements that should be reflown since they are __very__ long
   ...                                                                        /// and exceed the line limit.
thread 'main' panicked at 'Extracting `Bandaid`s from `State` must not fail. qed: BUG: Found a range which does not cover its own chunk', src/action/interactive.rs:162:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

and one test is still going 💥

thread 'documentation::chunk::test::find_line_length_docmacro' panicked at 'assertion failed: `(left == right)`
  left: `20`,
 right: `23`', src/documentation/chunk.rs:786:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    documentation::chunk::test::find_line_length_docmacro

[drahnr]

Nice! 👍 I have yet to test it, but looks good!

[drahnr]

With this change you cannot represent insertions with BandAid anymore, can you? A span is by definition at least length 1 since the start and end members are inclusive.

[KuabeM]

With this change you cannot represent insertions with BandAid anymore, can you? A span is by definition at least length 1 since the start and end members are inclusive.

We don't need any insertions. Any BandAid always replaces something.