[unstable option] blank_lines_lower_bound

[scampi]

Tracking issue for blank_lines_lower_bound

[Boscop]

It would be more useful if statements inside functions are not covered by this, only declarations!

Or is there another way to specify that I want to have at least 1 empty line between declarations (also between function-local declarations and whatever comes before/after)? (But not between statements in a function body.)

Example
Original Code (rustfmt will not change it with the default value of 0):

const A: u32 = 1;
enum B {
	C
}
impl B {
	// ...
}

Set to 1:

const A: u32 = 1;

enum B {
	C
}

impl B {
	// ...
}

[lunacookies]

What are the issues blocking the stabilisation of this option?

[calebcartwright]

@arzg - The process and requirements for stabilizing a configuration option are described here. Specifically, there are several issues that exist with blank_lines_lower_bound in released versions of rustfmt (1.x versions), for example #2954.

Some fixes/improvements to blank_lines_lower_bound have been made within the rustfmt source, but they have not yet been released. As such there are at least two stabilization requirements not yet for this configuration option:

• The design and implementation of the option are sound and clean.
• The option is well tested, both in unit tests and, optimally, in real usage.

[Systemcluster]

With blank_lines_lower_bound set to 0, rustfmt (1.4.27-nightly (580d826e 2020-11-16)) will still insert blank lines between fns, for example

impl A {
    fn a() { /* ... */ }
    fn b() { /* ... */ }
}

will get formatted to

impl A {
    fn a() { /* ... */ }

    fn b() { /* ... */ }
}

Is this correct? I.e., should this case be covered by this configuration option?

[nrc]

It would be nice to have slightly more finegrained control with this option, in particular, I would like to allow items which fit on a single line to have a 0 value, but larger items to have a 1 value.

[bluss]

This option doesn't seem to have a useful behaviour at the moment, is it something that will be tweaked?

My expectation would be that items (functions, struct definitions, similar) are separated by the lines (the documentation says items).

What actually happens is that attributes are spaced with one line before their functions, statements by one line etc, doc comments by one line before their functions etc. (Using blank_lines_lower_bound = 1 rustfmt 1.4.37-nightly (0bd2b19 2021-04-03)

@@ -1460,6 +1490,7 @@ impl<A> Clone for OwnedArcRepr<A> {
 /// [`RawArrayView`](type.RawArrayView.html) /
 /// [`RawArrayViewMut`](type.RawArrayViewMut.html) for the array type!*
 #[derive(Copy, Clone)]
+
 // This is just a marker type, to carry the mutability and element type.
 pub struct RawViewRepr<A> {
     ptr: PhantomData<A>,
@@ -1467,7 +1498,9 @@ pub struct RawViewRepr<A> {
 
 impl<A> RawViewRepr<A> {
     #[inline(always)]
+
     fn new() -> Self {
+
         RawViewRepr { ptr: PhantomData }
     }
 }
@@ -1620,6 +1686,8 @@ mod impl_raw_views;
 mod impl_cow;
 
 /// Returns `true` if the pointer is aligned.
+
 pub(crate) fn is_aligned<T>(ptr: *const T) -> bool {
+
     (ptr as usize) % ::std::mem::align_of::<T>() == 0
 }

[calebcartwright]

This option doesn't seem to have a useful behaviour at the moment, is it something that will be tweaked?

@bluss - your snippets are related to a bug (#2954) that's been fixed in source but not included yet in a release, it will (at a minimum) be corrected to only ensure spacing between items

[Keavon]

Hello, would it be possible to please get a update on the status of this being stabilized? Thank you very much.

[dcow]

When

This option doesn't seem to have a useful behaviour at the moment, is it something that will be tweaked?

@bluss - your snippets are related to a bug (#2954) that's been fixed in source but not included yet in a release, it will (at a minimum) be corrected to only ensure spacing between items

I am still experiencing this bug.

[ytmimi]

@dcow I'd suggest that you open up a new issue to fully describe the problem that you're experiencing