Rustup: Unexpected backtrace when adding rustup component

[worstpractice]

Thanks to everyone working on this awesome tool! :heart:

Problem
In a nutshell:

Steps

1. Run rustup component add llvm-tools in your terminal of choice

Notes
My everyday configuration is having RUST_BACKTRACE set to 1. It is also the configuration used in the screenshot above.

However, as I was investigating this, I tried setting RUST_BACKTRACE to full, hoping to learn more.

But doing so instead made the backtrace _disappear entirely_!

Is it a known or intentional behaviour that upping the verbosity level of backtraces can produce the opposite effect (silencing them, in practice)?

Surely the panic behavior itself didn't change as the value of RUST_BACKTRACE changed. (Right?)

Thanks in advance, apologies if anything crucial is missing or if I posted this in the wrong section.

Output of rustup --version:

rustup 1.24.1 (a01bd6b0d 2021-04-27)

Output of rustup show:

Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\WorstPractice.rustup

installed toolchains

stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)

active toolchain

nightly-x86_64-pc-windows-msvc (default)
rustc 1.54.0-nightly (5c0292654 2021-05-11)

[kinnison]

Thank you for this report, we print backtraces on normally handled errors if requested. This is normal behaviour (though not particularly helpful in this situation I concur).

@rbtcollins Should we perhaps suppress that backtrace reporting? it seems unhelpful and worries people.

[rbtcollins]

We might want to use RUSTUP_BACKTRACE only and not RUST_BACKTRACE, to make
us more invisible; OTOH that would probably get bug reports on the other
side of the equation: "why isn't this thing I know is written in rust not
reporting its backtraces".

Discriminating between a normal fault and an exceptional fault would be
good though perhaps nontrivial.

-Rob

On Sun, 16 May 2021 at 11:43, Daniel Silverstone @.*>
wrote:

Thank you for this report, we print backtraces on normally handled errors
if requested. This is normal behaviour (though not particularly helpful in
this situation I concur).

@rbtcollins https://github.com/rbtcollins Should we perhaps suppress
that backtrace reporting? it seems unhelpful and worries people.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rustup/issues/2769#issuecomment-841793149,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADZ7XQKRIT56WREYCEE2F3TN6HVZANCNFSM444QBMVA
.

[worstpractice]

To me (FWIW), a backtrace signals an unexpected internal malfunction in a piece of software.

I associate a simple error message with an expected error of some kind.

Judging from the backtrace, I'd have never suspected that to be the intended behaviour — never mind (what appears to be) an "error" originating outside the rustup binary itself.

AFAIK, it seems that the actual extent of the issue was merely (something akin to) a 404 being returned from the server that rustup queried for the user-provided component "llvm-tools".

If that's the case, I would consider the traceback to be highly confusing, and at odds with the extreme rarity of user-facing tracebacks in the bread-and-butter rust tooling. (I often see helpful error messages — but almost never outright backtraces — from the official suite of rust tooling, rustup included).

I've been dabbling with Rust since about the 2018 release, and this particular traceback stood out enough (to my eyes) for me to wonder if I'd actually found a "serious" bug in rustup.

Hope this input can be of any use. Thanks 🦀🌈

[rbtcollins]

@worstpractice No - no 404; we have a database we consulted and didn't find the thing you requested in it. That then gets signalled as an error, and the error reported. I certainly agree with the broad expectation; its just hitting a rough spot here, and our ability to hide it will depend on whether we can reliably determine exceptional vs routine errors in our CLI layer.