`rustup check` is missing a newline between toolchains and self

[epage]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

rustup - Up to date : 1.28.2 is at the end of the line of the last toolchain, rather than on its own line
From main

From release

Steps

1. Checkout main
2. Run cargo run --config env.RUSTUP_FORCE_ARG0=\'rustup\' -- check

Possible Solution(s)

No response

Notes

No response

Rustup version

❯ rustup --version
rustup 1.28.2 (e4f3ad6f8 2025-04-28)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.90.0 (1159e78c4 2025-09-14)`

Installed toolchains

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/epage/.rustup

installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (active, default)
beta-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
nightly-2023-11-13-x86_64-unknown-linux-gnu
nightly-2024-06-03-x86_64-unknown-linux-gnu
nightly-2024-09-10-x86_64-unknown-linux-gnu
nightly-2024-10-19-x86_64-unknown-linux-gnu
nightly-2025-01-27-x86_64-unknown-linux-gnu
nightly-2025-04-02-x86_64-unknown-linux-gnu
nightly-2025-06-26-x86_64-unknown-linux-gnu
1.0.0-x86_64-unknown-linux-gnu
1.48-x86_64-unknown-linux-gnu
1.48.0-x86_64-unknown-linux-gnu
1.56.0-x86_64-unknown-linux-gnu
1.57.0-x86_64-unknown-linux-gnu
1.58.0-x86_64-unknown-linux-gnu
1.60.0-x86_64-unknown-linux-gnu
1.64-x86_64-unknown-linux-gnu
1.64.0-x86_64-unknown-linux-gnu
1.65-x86_64-unknown-linux-gnu
1.65.0-x86_64-unknown-linux-gnu
1.66-x86_64-unknown-linux-gnu
1.66.0-x86_64-unknown-linux-gnu
1.70-x86_64-unknown-linux-gnu
1.70.0-x86_64-unknown-linux-gnu
1.71-x86_64-unknown-linux-gnu
1.71.0-x86_64-unknown-linux-gnu
1.71.1-x86_64-unknown-linux-gnu
1.72-x86_64-unknown-linux-gnu
1.74-x86_64-unknown-linux-gnu
1.75-x86_64-unknown-linux-gnu
1.76-x86_64-unknown-linux-gnu
1.80-x86_64-unknown-linux-gnu
1.80.1-x86_64-unknown-linux-gnu
1.81-x86_64-unknown-linux-gnu
1.83-x86_64-unknown-linux-gnu
1.83.0-x86_64-unknown-linux-gnu
1.84-x86_64-unknown-linux-gnu
1.85-x86_64-unknown-linux-gnu
1.86-x86_64-unknown-linux-gnu
1.86.0-x86_64-unknown-linux-gnu
1.88-x86_64-unknown-linux-gnu
1.89-x86_64-unknown-linux-gnu
1.90-x86_64-unknown-linux-gnu
stage1

active toolchain
----------------
name: stable-x86_64-unknown-linux-gnu
active because: it's the default toolchain
installed targets:
  aarch64-apple-darwin
  i686-unknown-linux-gnu
  i686-unknown-linux-musl
  powerpc-unknown-linux-gnu
  wasm32-unknown-unknown
  x86_64-pc-windows-gnu
  x86_64-pc-windows-msvc
  x86_64-unknown-linux-gnu
  x86_64-unknown-linux-musl
  x86_64-unknown-none

OS version

Linux

[rami3l]

Oh, it seems that since I have disabled self-update I'm missing that very line with my config so everything looks fine on my side 🤔

Also #4561 didn't expose that because self update during CI is a bit dangerous.

@FranciscoTGouveia this should be an easy fix; I'll handle that.

[rami3l]

@epage Wait a sec... It seems that I cannot reproduce this on my machine?

> cargo run --config="env.RUSTUP_FORCE_ARG0='rustup'" -- check
    Blocking waiting for file lock on build directory
   Compiling rustup v1.28.2 (/Users/rami3l/Documents/Code/rustup)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 7.05s
     Running `target/debug/rustup-init check`
beta-aarch64-apple-darwin - Up to date : 1.91.0-beta.9 (1f2519788 2025-10-17)
nightly-aarch64-apple-darwin - Up to date : 1.92.0-nightly (6501e64fc 2025-10-23)                                                                     
rustup - Up to date : 1.28.2

> cargo run -- --help
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/rustup-init --help`
rustup-init 1.28.2+336 (ca0c14a22 2025-10-22)
[..]

@djc Is it possible that another kind of whitespace handling was implemented specifically at the end?

[epage]

Note that I only see this when the new progress bars are used. If I pipe to a file, the newline is present.

[epage]

For some reason its no longer reproducing despite doing so just an hour or so ago. main hasn't changed in that time.

[rami3l]

I've noticed from #4560 (comment) that the last line but one has a long series of whitespaces at the end.

I'm not sure if that's relevant or essential to how indicatif is supposed to work; my guess would be that might be some regular line flushing technique; not entirely sure.

@epage What kind of terminal were you using in the above screenshots?

[epage]

I'm using wezterm with zellij

[djc]

I'm not sure if that's relevant or essential to how indicatif is supposed to work; my guess would be that might be some regular line flushing technique; not entirely sure.

It is intentional, though I've long since forgotten the details...