it does, to some extent, it depends on the tool and the aspect of the tool this also has negative effects: a bunch of debugging-only rustc flags are basically permaunstable and only available on nightly, which is silly (especially if you need to debug stable) - ThreadSky

manishearth.bsky.social • 1 day ago

it does, to some extent, it depends on the tool and the aspect of the tool

this also has negative effects: a bunch of debugging-only rustc flags are basically permaunstable and only available on nightly, which is silly (especially if you need to debug stable)

Comments

manishearth.bsky.social•1 day ago

generally "this will break CI but not end users" should be acceptable IMO, with steps taken to reduce the size of the impact (that's the part that failed here)

manishearth.bsky.social•1 day ago

I don't like that things like -Zunpretty and -Ztime-passes are unstable because someone "might rely on them in CI" or something :/

manishearth.bsky.social•1 day ago

generally, rustc has a pretty clear stability policy. cargo does too, informally, though it's a bit more lax in some ways (specifically, things like changing the resolver are in scope)

rustup has historically not changed enough to need one

manishearth.bsky.social•1 day ago

this is a good sign for rustup to figure out what it does and doesn't consider stable

("everything" isn't acceptable, full 100% stability effectively means never adding features, nothing has full 100% stability)

gregmorenz.bsky.social•1 day ago

> "everything" isn't acceptable.

Sure, but you can get most of the benefits without everything. Like rust does.

Some things are documented unstable (the size of structs, ordering of fields, ...). Some minor breaking changes are allowed (adding new trait impls, ...). In practice it's "close enough"

manishearth.bsky.social•1 day ago

I mean, yes, I'm not disagreeing with you, I'm just saying that stability policies are nuanced and hard to come up with.

rustup is not rustc, the answer for rustc is not going to be the answer for rustup, the rustup team has homework to do to figure it out

elizas.website•1 day ago

yeah. looking through the github discussion around this it feels like some folks were concerned about the potential ecosystem-wide flag day, but it doesn’t feel like it ended up being adequately communicated…

jscarrott.bsky.social•1 day ago

Guess I know what I'm doing tomorrow morning haha

barretts.club•16 hours ago

wish we had a -U (as in `-Uunpretty`) for stuff that isn’t a stable interface but is still useful

tylermandry.bsky.social•1 day ago

Hard agree with this, though I disagree that "anticipated" CI usage should be considered okay to break. I think we should document that the output of those flags is unstable and stabilize them!

manishearth.bsky.social•1 day ago

eh, hyrum's law means that all things can be depended upon by CI, and even anticipatable at times.

One could anticipate all kinds of CI breakage on all kinds of rustc PRs and halt development if that were actually the policy

It's a per case tradeoff, IMO.

manishearth.bsky.social•1 day ago

quite often the answer to a CI breakage is "great, your CI caught a problem, *as is its job*, and the onus is on your side to fix for it". I think that is 100% valid, and views otherwise tend to be super absolutist

manishearth.bsky.social•1 day ago

for example, I may soon write a bit of CI that ensures that some of our APIs do not pull in any panic machinery. This is fiddly and can depend on the optimizer. That's fine, if the CI breaks on a rust upgrade, it's on me to investigate how to keep our APIs panic-free, the CI did its job!!

Comments

Posting Rules

Reply