[unstable option] file_lines

[scampi]

Tracking issue for file_lines

[scampi]

original issue: #1514

[Xanewok]

Will this option be stabilized anytime soon? We use it for quite some time in RLS for the Range Formatting and it seems to work without any problems.

One thing that sometimes happens IIRC is that it can "grab" remaining parts of the selected expression/AST node outside of the specified range by 1 or 2 lines but it always seemed like it did a reasonable thing, e.g. it was hard to imagine how you could only partially format the specified range.

RLS also uses feature gating for this, so if it were made stable we could offer it to our users out of box, without them having to opt-in into unstable features. cc @nrc

[scampi]

One thing that sometimes happens IIRC is that it can "grab" remaining parts of the selected expression/AST node outside of the specified range by 1 or 2 lines but it always seemed like it did a reasonable thing, e.g. it was hard to imagine how you could only partially format the specified range.

@Xanewok Sounds like that is by design, see #1514 (comment) and #1514 (comment).

I have combed through the issues mentioning or related to file-lines in order to get a better idea of the current state of that option. Here is an overview and my take on them:

• Ability to format inline functions with dependencies through stdin #1290: a use case for formatting a selected portion of code. Its priority is low and therefore shouldn't prevent stabilisation I think.
• Format markdown documents containing Rust #2036: the ability to format rust code inside non-rust files, e.g., markdown. That is an improvement and doesn't prevent stabilisation.
• Tracking issue: performance #338 (comment): some improvements wrt performance.
• Fail to format nested mod with relative path on windows #1873: that is bug wrt file path on Windows. I think that's a blocker.
• Comment inconsistency with file-lines option #3442: problem retaining comment spacing. A seemingly little bug but probably blocker.

Overall, I would say 2 issues are needed to complete stabilisation. @topecongiro ?

[jsgf]

#3442 is a blocker for us to be able to use --file-lines at all - it produces inconsistent and bimodal results.

There's also another bug I haven't narrowed down yet where rustfmt seems to (sometimes) infinitely indent the internals of macro definitions, which could also be --file-lines related.

[nrc]

Looks like #3442 is fixed now. It is by design that file lines 'rounds up'. We need to round up to the nearest AST node in the best case and we are currently very conservative (I think round up to the nearest item, or maybe even module). So while we could do better, I don't think we need to block stabilisation (although we would need to think about what exactly stability means then). Note that the LSP spec permits rounding up.

[Xanewok]

@scampi is there any issue left that's specifically related to file_lines which blocks this stabilization?

[scampi]

@Xanewok I believe #1873 is the outstanding issue

[joshtriplett]

All of the issues mentioned as blockers seem to have been addressed. Is there any remaining blocker to stabilizing --file-lines?

[calebcartwright]

All of the issues mentioned as blockers seem to have been addressed. Is there any remaining blocker to stabilizing --file-lines?

I believe #4053 may contain some issues that need investigation, but haven't looked to closely.

[euclio]

Can this be used with stdin?

EDIT: I see that you can provide "file": "stdin", but I don't see this documented.

[euclio]

I've been using this via rls and rust-analyzer, and haven't noticed any issues. I'm interested in seeing this stabilized.

[not-my-profile]

As I reported in #5136 file-lines currently changes whitespace outside of the given range. That should be fixed before stabilization.