Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[unstable option] struct_field_align_threshold #3371

Open
scampi opened this issue Feb 13, 2019 · 7 comments
Open

[unstable option] struct_field_align_threshold #3371

scampi opened this issue Feb 13, 2019 · 7 comments
Labels
unstable option tracking issue of an unstable option

Comments

@scampi
Copy link
Contributor

scampi commented Feb 13, 2019

Tracking issue for unstable option: struct_field_align_threshold

@scampi scampi added the unstable option tracking issue of an unstable option label Feb 13, 2019
@scampi scampi changed the title [unstable option] unstable option: struct_field_align_threshold [unstable option] struct_field_align_threshold Feb 18, 2019
@jmillikin
Copy link

Two issues I've noticed with this option:

First, it interacts poorly with hard_tabs. The + lines ought to be tabbed equal to len and then space-aligned afterward, but they're being given block indentation instead. Users with different tab lengths will see weird formatting.

This might be easier to visualize by copying the following examples to an editor with space highlighting.

Bad:

	.push_sized(&fuse_kernel::fuse_out_header {
		len:    (size_of::<fuse_kernel::fuse_out_header>()
			+ fuse_kernel::FUSE_COMPAT_ENTRY_OUT_SIZE
			+ size_of::<fuse_kernel::fuse_open_out>()) as u32,
		error:  0,
		unique: REQUEST_ID,
	})

Would be good:

	.push_sized(&fuse_kernel::fuse_out_header {
		len:    (size_of::<fuse_kernel::fuse_out_header>()
		         + fuse_kernel::FUSE_COMPAT_ENTRY_OUT_SIZE
		         + size_of::<fuse_kernel::fuse_open_out>()) as u32,
		error:  0,
		unique: REQUEST_ID,
	})

Secondly, I don't think block-formatted literals should be aligned -- or it should maybe be disable-able. This is how gofmt does it, and it is easier to read when working with mixed primitives and compound literals.

Example of poor formatting:

  .push_sized(&fuse_kernel::fuse_entry_out {
    // ...
    entry_valid_nsec: 0,
    attr_valid_nsec:  0,
    attr:             fuse_kernel::fuse_attr {
      ino: 11,
      ..Default::default()
    },
  })

What I would expect:

  .push_sized(&fuse_kernel::fuse_entry_out {
    // ...
    entry_valid_nsec: 0,
    attr_valid_nsec:  0,
    attr: fuse_kernel::fuse_attr {
      ino: 11,
      ..Default::default()
    },
  })

@SOF3
Copy link

SOF3 commented Sep 12, 2022

Is there a similar option for function parameters?

@wusticality
Copy link

Will this ever be made available in stable Rust?

@ytmimi
Copy link
Contributor

ytmimi commented Mar 30, 2023

@wusticality please see #5365

@theon
Copy link

theon commented Feb 18, 2024

Thanks for adding this option. An issue I have noticed whilst using it is that the formatting isn't applied when using ..Default::default(). For example, I get:

StandardMaterial {
    base_color_texture: Some(asset_server.load("textures/card_back.png")),
    cull_mode: Some(Face::Front),
    fog_enabled: false,
    unlit: true,
    alpha_mode: AlphaMode::Blend,
    ..Default::default()
}

whereas I would expect:

StandardMaterial {
    base_color_texture: Some(asset_server.load("textures/card_back.png")),
    cull_mode:          Some(Face::Front),
    fog_enabled:        false,
    unlit:              true,
    alpha_mode:         AlphaMode::Blend,
    ..Default::default()
}

@ytmimi
Copy link
Contributor

ytmimi commented Feb 18, 2024

@theon thanks for sharing. When you have a chance can you create a new issue outlining the problem in more detail. I think it would be best to track this in a separate thread.

@theon
Copy link

theon commented Feb 18, 2024

Thanks @ytmimi, I have raised #6080

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unstable option tracking issue of an unstable option
Projects
None yet
Development

No branches or pull requests

6 participants