rustfmt icon indicating copy to clipboard operation
rustfmt copied to clipboard

Dioxius macros confuse rustfmt

Open uzytkownik opened this issue 1 year ago • 8 comments

Rustfmt formats:

fn Layout() -> Element {
    fn Links() -> Element {
        rsx! {
            nav {
                ul {
                    id: "main-nav",
                    class: "nav nav-pills",
                    for item in RouteDiscriminants::iter() {
                        MenuItem { item }
                    }
                }
            }
        }
    }
    rsx! {
        header {
            class: "text-bg-dark d-flex justify-content-center py-3",
            Links {}
        }
        main {
            class: "col-lg-8 mx-auto p-4 py-md-5",
            Outlet::<Route> { }
        }
    }
}

into:

fn Layout() -> Element {
    fn Links() -> Element {
        rsx! {
            nav {
            ul {
                id: "main-nav",
                class: "nav nav-pills",
                for item in RouteDiscriminants::iter() {
                MenuItem { item }
                }
            }
            }
        }
    }
    rsx! {
    header {
        class: "text-bg-dark d-flex justify-content-center py-3",
        Links {}
    }
    main {
        class: "col-lg-8 mx-auto p-4 py-md-5",
        Outlet::<Route> { }
    }
    }
}

uzytkownik avatar Jul 06 '24 03:07 uzytkownik

@uzytkownik what version of rustfmt are you using? I'm unable to reproduce the issue locally building rustfmt from source.

ytmimi avatar Jul 06 '24 04:07 ytmimi

@ytmimi Hmm. It looks something very strange goes on with tabs. It looks like rustfmt does not convert them into spaces which seems to be strange. I would expect based on documentation to have them converted into spaces by default- hard_tabs.

Outside of that it seems to be mismatch of tab_spaces between rustfmt and editor. I disabled tabs in editor fixing the problem but it seems to me that behaviour should be clarified in documentation or (even better) hard_tabs would convert them into spaces.

uzytkownik avatar Jul 06 '24 04:07 uzytkownik

Also, which configuration options are you using?

ytmimi avatar Jul 06 '24 04:07 ytmimi

@ytmimi None. I just run cargo fmt. No configuration.

uzytkownik avatar Jul 06 '24 04:07 uzytkownik

Got it, so this was just a mismatch between rustfmt and your editors settings?

ytmimi avatar Jul 06 '24 05:07 ytmimi

@ytmimi Sorry. As proximate cause (which was confusing for me) yes. Though I assumed by default cargo fmt converts to spaces based on hard_tabs documentation.

uzytkownik avatar Jul 06 '24 05:07 uzytkownik

I'm not sure if the issue is with rustfmt. I ran a little test, and it seems that when hard_tabs=false is set leading tab characters are replaced with spaces based on the value of tab_spaces.

Given the following input that uses tabs:

fn Layout() -> Element {
	fn Links() -> Element {
		rsx! {
			nav {
				ul {
					id: "main-nav",
					class: "nav nav-pills",
					for item in RouteDiscriminants::iter() {
						MenuItem { item }
					}
				}
			}
		}
	}
	rsx! {
		header {
			class: "text-bg-dark d-flex justify-content-center py-3",
			Links {}
		}
		main {
			class: "col-lg-8 mx-auto p-4 py-md-5",
			Outlet::<Route> { }
		}
	}
}

Running rustfmt with hard_tabs=false (the default, but I explicitly configured it) outputs:

fn Layout() -> Element {
    fn Links() -> Element {
        rsx! {
            nav {
                ul {
                    id: "main-nav",
                    class: "nav nav-pills",
                    for item in RouteDiscriminants::iter() {
                        MenuItem { item }
                    }
                }
            }
        }
    }
    rsx! {
        header {
            class: "text-bg-dark d-flex justify-content-center py-3",
            Links {}
        }
        main {
            class: "col-lg-8 mx-auto p-4 py-md-5",
            Outlet::<Route> { }
        }
    }
}

ytmimi avatar Jul 06 '24 06:07 ytmimi

Let me know if you're able to recreate the scenario (and provide sample input) that lead to the odd indentation you noted in your original comment

ytmimi avatar Jul 06 '24 06:07 ytmimi

@uzytkownik it's been a while since I've heard from you on this, and I'm still unable to reproduce the error so I'm going to close this.

ytmimi avatar Jan 14 '25 01:01 ytmimi