rustup icon indicating copy to clipboard operation
rustup copied to clipboard

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

Open epage opened this issue 2 months ago • 7 comments

Verification

  • [x] I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
  • [x] 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 Image

From release Image

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

epage avatar Oct 23 '25 16:10 epage

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 avatar Oct 24 '25 02:10 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?

rami3l avatar Oct 24 '25 04:10 rami3l

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

epage avatar Oct 24 '25 15:10 epage

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

epage avatar Oct 24 '25 17:10 epage

I've noticed from https://github.com/rust-lang/rustup/issues/4560#issuecomment-3441006259 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?

rami3l avatar Oct 25 '25 02:10 rami3l

I'm using wezterm with zellij

epage avatar Oct 25 '25 02:10 epage

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...

djc avatar Oct 25 '25 11:10 djc