bootstrap: force download-rustc=if-unchanged even if settings differ

[RalfJung]

I'd like to have debug assertions enabled for local rustc builds, but if I didn't change rustc then I am okay with just downloading the prebuilt rustc even if it does not have debug assertions. I'll hopefully only have to debug rustc if I actually changed it. :)

Would be nice to have a way to force the download even if settings differ.

[jyn514]

@rustbot label A-download-rustc T-bootstrap

[jieyouxu]

I'd like to have debug assertions enabled for local rustc builds, but if I didn't change rustc then I am okay with just downloading the prebuilt rustc even if it does not have debug assertions. I'll hopefully only have to debug rustc if I actually changed it. :)

Note that compiletest has no other way other than relying on bootstrap to provide info about whether the rustc under test is built with debug assertions. So even if the forcing CI rustc option is specified, ./x test on tests/ either has to fail, or skip tests that require debug assertions (among other cases whether CI rustc differs with actual local rustc config). Skipping seems sketchy.

Or, is the proposed force behavior only for check/build cases?

[RalfJung]

Ah, good point.

I will probably not run the compiler tests if I didn't change the compiler. So having it just refuse to run them would be fine. But I can see how that gets messy...

Or, is the proposed force behavior only for check/build cases?

It's also for "run library tests", but not for "run compiler tests".

[jieyouxu]

Yeah, which is why that seems a bit tricky (cuz if you only fail the build for tests/ that also feels self-inconsistent).

It's also for "run library tests", but not for "run compiler tests".

To make matters worse, note that we have some library tests within tests/ because its hard to write as library/ unit/crate tests 😆. But yeah, I see what you mean re. library/ tests.

[RalfJung]

note that we have some library tests within tests/ because its hard to write as library/ unit/crate tests

When I said "library tests" I meant "tests in library/". :)

[jieyouxu]

(Yes, I added the clarification with an edit but raced with you)

[jieyouxu]

I will probably not run the compiler tests if I didn't change the compiler. So having it just refuse to run them would be fine. But I can see how that gets messy...

This is also kinda tricky from a UX perspective. Because then, you can have a set of configuration options which works for ./x {check,build} or even ./x test library/, but which becomes rejected by ./x test tests/ only when you try to run it 🤔

[RalfJung]

Yeah it's not trivial.^^

For now I changed my settings, I rarely need debug assertions. This is not high priority. But once the dust settles around the transition, maybe we can find a way to find more ergonomic ways for working with debug assertions occasionally.