External Publication
Visit Post

Code compiles on playground but fails when passed via stdin to rustc

Rust Internals [Unofficial] June 29, 2026
Source

I'm genuinely confused by what appears to be the prevailing negative view of build probes in principle. (I'm quite able to understand a negative view of poorly-created build probes in practice)

Here's my thinking. What am I missing? Is it another implicit social contract?

  1. No other crate can force you onto nightly or any other version of stable.

Nemo157:

I would really like a way to just say "I'm on at least the latest stable when you were published, use all those features" and bypass any attempt at detecting for MSRV's I don't care about or unstable features I do not want used.

 * The toolchain version is decided by whoever is compiling the final binary. It should be up to them and only them what is used.
 * If that's you in this case - how are you being forced to use an experimental nightly feature?
 * If you're a lib in the middle - why should you be able to restrict your downstream user's choice of toolchain?
  1. As a lib developer I may want to provide additional functionality which requires experimental nightly features

    • if this is in the form of extensions to the API, via a feature - the direct consumer needs actively use the additional API, so it makes sense that they set a feature in their dependency (on me)
    • if this is via a consistent API, via a build probe - it doesn't make sense to require a direct consumer lib to make a choice for their downstream users. Should they opt in and only support others on nightly? Or opt out and their users lose the benefit?
  2. The fewer people use nightly experimental features, the longer it takes to get meaningful feedback on them and the slower the language develops.

    • The very real impact of this are year-long timelines for amazing ergonomic changes - that's not due to lack of effort etc. from the various teams, that's simply due to the reality of usage levels and the time needed to get good data.
    • To my mind, taking the time as a lib developer to try to incorporate nightly features in a way which allows stable-by-default to "just work" and gives value add for those who wish to use nightly is the least I can do to support the people who devote huge time and effort into improving the language.

RalfJung:

I wish we had proper cargo support for build probes (or something else that alleviates the need for build probes) so people wouldn't have to write their own hacks to substitute for lack of official support.

I'm not sure that anything short of well-written probes and thoughtful API design would solve the issue. I've recently tried to lib-ify the probes that I use - and it's not even possible to have a general probe for "do you need this #![feature(...)]" that works in every case.

Perhaps providing a section in the unstable book on these topics would help with reducing the number of "hacks" and increasing the number of well-written probes & APIs?

Discussion in the ATmosphere

Loading comments...