# Code compiles on playground but fails when passed via stdin to rustc **URL:** \ **Category:** Uncategorized\ **Created:** [June 11, 2026, 5:21pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393 "2026-06-11T17:21:59Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![ekuber](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ekuber/32/1646_2.png) [@ekuber](https://internals.rust-lang.org/u/ekuber)\ **Post date:** [June 21, 2026, 10:53pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/21 "2026-06-21T22:53:55Z")
Do note that I implemented this as an undismisable note, which could also be a warning (that wouldn't be affected by forbid warnings, if iirc, as that only looks at lints, but might be getting things wrong there). The only people affected would be those explicitly comparing textual compiler output in scripts. ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [June 23, 2026, 2:47pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/22 "2026-06-23T14:47:41Z")
> [@cuviper](#): > > If that's going to be another of these [environment variables](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts), perhaps something like `CARGO_PKG_EDITION`, then that sounds great, and I would probably change `autocfg` to use that by default. I don't know how a compiler feature could supersede that though, because I would want the edition of the package with the build script, not of `autocfg` itself. Around the time we approved an environment variable, there started talk among T-lang to add an `edition` cfg which would then be exposed to build scripts as `CARGO_CFG_EDITION`. That went through several proposals, delaying it. The latest has been untouched for enough time that it might not be worth waiting on anymore and to instead use `CARGO_PKG_EDITION`. ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [June 24, 2026, 2:45pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/23 "2026-06-24T14:45:27Z")
~~I'm also struggling to see how this would work. To my understanding the cargo env variables are set once for a cargo invocation\[1\]. Build scripts and edition selection are unique to a specific crate, wherever it sits in the dependency tree; not driven by the one(s) at the top of the chain which triggered the build.~~ Edit: got it now \[2\] weird how I can spend 2 days trying to figure something out and then get it almost straight away after asking publicly! * * * 1. building all crates in parallel and the global-nature of env vars suggests this cannot be done any other way(?) 2. prefix the call with the env cars directly ---
**Author:** ![bjorn3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bjorn3/32/2736_2.png) [@bjorn3](https://internals.rust-lang.org/u/bjorn3)\ **Post date:** [June 24, 2026, 4:37pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/24 "2026-06-24T16:37:16Z")
Cargo sets a bunch of env vars for each build script invocation with different values depending on the package they are part of. ---
**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\ **Post date:** [June 27, 2026, 11:51am UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/25 "2026-06-27T11:51:51Z")
> [@Nemo157](#): > > I almost think it would be a good thing to break `autocfg` occasionally and try to influence people away from using it. I run into crates that have issues working on nightly over, and over, _and over_ because of bad auto-detection. 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_. 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. But, well, everyone only has finite capacity so here we are. There is an env var you can set which makes `rustc -vV` claim that this is "stable" even if you are on nightly; this will disable most of this kind of auto-detection (and it's very clearly a bug in the ones that do not get disabled): [`RUSTC_OVERRIDE_VERSION_STRING`](https://doc.rust-lang.org/stable/unstable-book/compiler-environment-variables/RUSTC_OVERRIDE_VERSION_STRING.html). ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [June 29, 2026, 3:04pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/26 "2026-06-29T15:04:10Z")
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. 2. As a lib developer I may want to provide additional functionality which requires experimental nightly features 3. The fewer people use nightly experimental features, the longer it takes to get meaningful feedback on them and the slower the language develops. > [@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](https://github.com/MusicalNinjaDad/rust/blob/901259326138fb9726709487bb5000f697dc82f6/ninja-build_rs/src/nightly.rs#L116) 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? ---
**Author:** ![Nemo157](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nemo157/32/11585_2.png) [@Nemo157](https://internals.rust-lang.org/u/Nemo157)\ **Post date:** [June 29, 2026, 3:30pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/27 "2026-06-29T15:30:35Z")
> [@MusicalNinjaDad](#): > > The toolchain version is decided by whoever is compiling the final binary. Which is me, I only care about build probes when they execute on my system (maybe because I'm developing an application, maybe when I'm compiling the tests for my library). > [@MusicalNinjaDad](#): > > If that's you in this case - how are you being forced to use an experimental nightly feature? Because I use a nightly compiler to take advantage of unstable toolchain features that don't impact the code, just improve the developer experience e.g. Cargo's workspace-feature-unification. But dependencies see that I am using a nightly compiler and attempt to use other unstable library or compiler features that I don't want them to. > [@MusicalNinjaDad](#): > > As a lib developer I may want to provide additional functionality which requires experimental nightly features And you still can, you should just provide a way to allow users to opt-in to this (e.g. via `--cfg` flags or environment variables). If users do not, don't just assume you can use them (since build probes are commonly wrong and cause compilation failures, e.g. [latest instance of this I've found](https://github.com/sunfishcode/io-extras/issues/38)). > [@MusicalNinjaDad](#): > > The fewer people use nightly experimental features, the longer it takes to get meaningful feedback on them and the slower the language develops. If I do not know that a dependency of mine has enabled an unstable feature, I am not going to give feedback on it anyway. By surfacing the feature as something the final developer actually enables that gives you a chance to link to the tracking issue and suggest they go leave feedback if they use it. ---
**Author:** ![kpreid](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kpreid/32/8484_2.png) [@kpreid](https://internals.rust-lang.org/u/kpreid)\ **Post date:** [June 29, 2026, 3:39pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/28 "2026-06-29T15:39:25Z")
As the person choosing the toolchain to build with, I may be using nightly for any number of reasons; in particular, I may be using it to get access to flags useful for debugging that aren't stable, or to use a newer compiler version that might have fixed a bug. When I switch to nightly for one of those reasons, I _don't_ want my project's dependencies to _also_ implicitly change to making use of unstable features. I don't want them to be compiling different code. I don't want them to be exercising parts of the compiler that are marked unstable. I want everything about those dependencies to be exactly the same except what I chose to change (the compiler version) so that the results of my experiment are as controlled as possible. That said, I would also enjoy having a sort of global feature flag (perhaps just a conventional environment variable, or `cfg` to stick in `RUSTFLAGS`?) to tell every dependency "yes, _do_ use all the unstable features you would like to", for the testing of nightly features. But I don't want that to be implied by any usage of nightly at all, which is what happens when libraries use build probes for unstable features. ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [June 29, 2026, 5:46pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/29 "2026-06-29T17:46:02Z")
> [@MusicalNinjaDad](#): > > Here's my thinking. What am I missing? Is it another implicit social contract? Beyond the anecdotes given, there is a general principle within the Rust Project that unstable features only impact those who have opted in. We should not be gating functionality based on the channel. This makes it much safer for people to run nightly. The rare exception is when we are needing extra testing on something right before stabilization. Libraries auto-enabling features are running counter to that principle. ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [June 29, 2026, 5:48pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/30 "2026-06-29T17:48:03Z")
> [@kpreid](#): > > I may be using it to get access to flags useful for debugging that aren't stable, or to use a newer compiler version that might have fixed a bug. > > When I switch to nightly for one of those reasons, I _don't_ want my project's dependencies to _also_ implicitly change to making use of unstable features. That makes perfect sense. > [@kpreid](#): > > That said, I would also enjoy having a sort of global feature flag (perhaps just a conventional environment variable, or `cfg` to stick in `RUSTFLAGS`?) to tell every dependency "yes, _do_ use all the unstable features you would like to", for the testing of nightly features. **With a small twist I'd agree that that is a great idea ...** Why not the other way around? Instead of requiring an opt-in to a full nightly experience on nightly, provide an opt-in-to-only which then disables everything else. That way those who need or want very granular control have it with no extra effort and those who want "full nightly" also have that with no extra effort. It's the idea of either requiring an opt-in if you don't want granular control, or, worse, if you don't want an arbitrary set of pre-defined features that irks me. > [@Nemo157](#): > > By surfacing the feature as something the final developer actually enables and there's the rub ... the final developer cannot enable a feature if they are consuming via a transitive dependency. Yes - you could require them to set a cfg flag or env variable manually ... and some choose that route. Personally, I prefer a crate that documents clearly if they auto-detect & use nightly features to one that makes me go through that hassle, and choose accordingly (just as others will choose the opposite) ---
**Author:** ![epage](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/epage/32/3171_2.png) [@epage](https://internals.rust-lang.org/u/epage)\ **Post date:** [June 29, 2026, 5:48pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/31 "2026-06-29T17:48:45Z")
> [@kpreid](#): > > That said, I would also enjoy having a sort of global feature flag (perhaps just a conventional environment variable, or `cfg` to stick in `RUSTFLAGS`?) to tell every dependency "yes, _do_ use all the unstable features you would like to", for the testing of nightly features. But I don't want that to be implied by any usage of nightly at all, which is what happens when libraries use build probes for unstable features. I have wondered about replacing `nightly` cargo features with [Pre-RFC: Mutually-excusive, global features](https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618) . More recently, I found out about `-Zallow-features` and wonder if there is something there we could build up to better support these use cases, including forwarding that to build scripts and proc-macros for the code they generate. > **[allow-features - Unstable Features - The Cargo Book](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#allow-features)** > > Experimental Cargo features are only available on the nightly channel. You are encouraged to experiment with these features to see if they meet your needs, and if there are any issues or problems. Check the linked tracking issues listed below for... ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [June 29, 2026, 5:56pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/32 "2026-06-29T17:56:33Z")
> [@epage](#): > > More recently, I found out about `-Zallow-features` and wonder if there is something there we could build up to better support these use cases, including forwarding that to build scripts and proc-macros for the code they generate. > [@MusicalNinjaDad](#): > > Why not the other way around? Instead of requiring an opt-in to a full nightly experience on nightly, provide an opt-in-to-only which then disables everything else. Sounds like that actually already exists. (Thanks - another thing I learned today!) So, what's the concern about a build probe which correctly reacts to `RUSTFLAGS="-Zallow-features="` by _not_ enabling any nightly features? If you want to limit what is enabled on nightly for reasons like those above, set the env variable, ... (I just checked and all my probes react correctly to it - so it's not rocket science, just so under-documented that getting probes right is much harder than it needs to be) ---
**Author:** ![Nemo157](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nemo157/32/11585_2.png) [@Nemo157](https://internals.rust-lang.org/u/Nemo157)\ **Post date:** [June 29, 2026, 6:07pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/33 "2026-06-29T18:07:58Z")
Did you try when set via `CARGO_UNSTABLE_ALLOW_FEATURES` too? That’s probably the more common interface to the functionality now that it exists, and that’s what I’ve been running into a lot of buggy probe handling for recently. (And it’s kind of an eternal fact that every time the interface for this sort of thing improves, build scripts will fail to handle it because they’re kind of fail open, instead of fail closed; I remember long ago when none handled RUSTFLAGS correctly either). ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [June 29, 2026, 6:15pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/34 "2026-06-29T18:15:31Z")
> [@Nemo157](#): > > Did you try when set via `CARGO_UNSTABLE_ALLOW_FEATURES` too? Yep - and no that won't work - for the same reason as the original post in this thread. I'd consider that a different issue though and question whether `CARGO_UNSTABLE_ALLOW_FEATURES` should remain the more common approach given `-Zallow-features` now exists, offers the same and doesn't suffer from the problem of "only relevant when rustc is invoked via cargo" (or whether cargo could set `-Zallow-features` based on this setting) > [@Nemo157](#): > > And it’s kind of an eternal fact that every time the interface for this sort of thing improves, build scripts will fail to handle it because they’re kind of fail open, instead of fail closed; I remember long ago when none handled RUSTFLAGS correctly either If I understand you correctly - that's bad build script design. (I'd expect a build script to see "is rustc\[1\] actually going to be able to compile this code in the current environment") * * * 1. rustc, not cargo. Although I'd see nothing in principle against cargo developing an equivalent set up support functionality. In practice it's a lot of work for something very controversial ---
**Author:** ![Nemo157](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nemo157/32/11585_2.png) [@Nemo157](https://internals.rust-lang.org/u/Nemo157)\ **Post date:** [June 29, 2026, 8:58pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/35 "2026-06-29T20:58:03Z")
> [@MusicalNinjaDad](#): > > and question whether `CARGO_UNSTABLE_ALLOW_FEATURES` should remain the more common approach given `-Zallow-features` now exists It's the other way around, `rustc -Zallow-features` has existed for years longer than `cargo -Zallow-features` (but I'm pretty sure that is also years old at this point). The latter is a superset of the former, it controls both cargo and rustc unstable features, and has a much better UX for shared workspace definitions in its TOML form. ---
**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\ **Post date:** [June 30, 2026, 12:20pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/36 "2026-06-30T12:20:20Z")
> [@MusicalNinjaDad](#): > > So, what's the concern about a build probe which correctly reacts to `RUSTFLAGS="-Zallow-features="` by _not_ enabling any nightly features? Basically every build probe is broken in subtle ways. It's not currently possible to construct a correct build probe, cargo [does not provide enough information](https://github.com/rust-lang/cargo/issues/11244#issuecomment-2326780810). `autocfg` is about as good as it gets, but a lot of crates roll their own build probes and many of them are ways worse. By asking about "a correct build probe" you are asking about a hypothetical alternative universe. In practice, a large fraction of build probes are broken. And even perfect build probes still have the wrong polarity: nightly features should be opt-in, not opt-out. That's how the entire Rust nightly feature system is designed. I shouldn't have to set an env var that says "please actually give me a reliable developer experience where I can update my compiler without breaking the build". Defaulting to "unreliable developer experience" is a terrible default. It is frustrating to see that principle constantly violated by a small set of crates, to the detriment of nightly users and compiler maintainers that want to do normal nightly feature development (i.e., change/break how nightly feature work) or that need to debug regressions. I understand that there's an actual need here from the side of crate developers. But instead of running ahead with a broken non-solution, I would have hoped there would be some attempt at doing something standardized that actually works for everyone involved. Sadly, to my knowledge, that was never even attempted. Now my best hope is that we do get global features in cargo and we can standardize on a global feature to control whether crates should use nightly features that they don't strictly need. ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [June 30, 2026, 1:32pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/37 "2026-06-30T13:32:54Z")
I realise that my previous comments can easily appear argumentative (and have thought a lot about this since my last post here). I'm sorry for that, it was not my intention. I think I've understood the complex web of intertwined concerns, needs & historical frustration - here's my attempt to summarise it ### Groups using nightly There are two, relevant, groups of rust users who have very different expectations and needs when they use nightly: #### Group A - safety is a requirement These are people using rust because the safety guarantees provide safety(!). Obvious members are regulated industries where failure can cost human lives; rust for linux, ... I get the feeling that this is either where you are @Nemo157, or at least closely related to your mindset. Every use of nightly requires a clear risk assessment. - Developers may need to use nightly to allow debugging support etc. - they should be able to guarantee that their local work is otherwise identical to the final built product. - A small, reviewed, whitelisted subset of experimental features may be required to make the product work - each of these is well considered, documented & risk-assessed. - Build scripts are needed to support product-specific technical requirements. This group really needs the ability to work on a nightly toolchain and have everything act just like stable except where specifically whitelisted (whether developer or product related) #### Group B - safety is an ergonomic benefit These are people using rust because the safety guarantees make coding nicer/easier/more ergonomic. These are the evangelistic colleagues who grab you at the coffee machine and say "let me show you rust". I'd consider myself in this category. Channel selection is a mainly binary decision: nightly or stable? - sticking to stable can be frustrating - so many ergonomic improvements are available on nightly for a very long time before they stabilise. - using nightly is viable for binaries but colours libs. - the lib eco-system generally avoids nightly features, even where these could provide a more ergonomic API. - build scripts provide a way to remove the colouring and support stable & nightly. ### Technical blockers - cargo does not provide details of `unstable.allow-features` to build scripts (+ other settings?) & has previously been against extending build-script-specific support - there is effectively no documentation of "how to write a good build script" - there is no documentation on how to probe for the availability of a nightly feature - no specific probes are available from trusted sources ### Facits > [@epage](#): > > there is a general principle within the Rust Project that unstable features only impact those who have opted in For "Group A" this is at the granularity of "I opted in to only these specific features". For "Group B" it is "I opted in by using nightly". > [@RalfJung](#): > > Basically every build probe is broken in subtle ways. It's not currently possible to construct a correct build probe, cargo [does not provide enough information](https://github.com/rust-lang/cargo/issues/11244#issuecomment-2326780810). That means someone is always going to be upset. As long as there are different groups with different needs (& usually only a few members who consider the other groups may even exist - I'd consider all the participants here to be the "considerate" category BTW) then each build script author needs to decide how to handle these edge cases and given that many come from "Group B" that means usually > [@Nemo157](#): > > build scripts will fail to handle it because they’re kind of fail open, instead of fail closed ### Thoughts, ideas & opinions 1. Build probes are here to stay - as much as they cause problems. (no value judgement, just raw practical observation, which has been stated by others who are active in this thread too) 2. Perhaps providing (edit) `CARGO_UNSTABLE_FLAGS` (probably outputting it (edit: from the GlobalContext) [here](https://github.com/rust-lang/cargo/blob/1ee1ce4eaec3c2433e0b28fc3e903ee917c5eea8/src/cargo/core/compiler/custom_build.rs#L465) - based on a first reading of the code) would be better than not? 3. Documenting best practices & providing well-thought-out probes would reduce the average bugginess. The cost is "implicit approval", the cost of status-quo is "constantly broken probes". 4. Thank you for reminding me of the needs of "Group A". I will add a "--cfg namespace=stable" to all my nightly-testing build scripts (via my personal lib for consistency). At least that way people can fully opt out of the probes. I target mainly "Group B" types so a "must opt in" is not suitable for the main target audience. I know this is not what most on this thread would consider "ideal" or "correct" - but would it at least be "enough" @Nemo157? ---
**Author:** ![Nemo157](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nemo157/32/11585_2.png) [@Nemo157](https://internals.rust-lang.org/u/Nemo157)\ **Post date:** [June 30, 2026, 1:54pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/38 "2026-06-30T13:54:15Z")
My case is about _stability_ rather than safety. We use nightly for a few features we believe are worth the cost of lower stability, we have looked at the tradeoff of not using them vs. the chance of them causing issues and how we would remove our usage. We want to be able to very freely update our compiler without having to worry if dependencies will break. ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [July 1, 2026, 7:44pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/39 "2026-07-01T19:44:45Z")
> [@Nemo157](#): > > My case is about _stability_ rather than safety. Got it, I see the subtle difference. thanks for the clarification. ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [July 1, 2026, 8:03pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/40 "2026-07-01T20:03:48Z")
> [@RalfJung](#): > > Basically every build probe is broken in subtle ways. It's not currently possible to construct a correct build probe, cargo [does not provide enough information](https://github.com/rust-lang/cargo/issues/11244#issuecomment-2326780810). > > `autocfg` is about as good as it gets, but a lot of crates roll their own build probes and many of them are ways worse. By asking about "a correct build probe" you are asking about a hypothetical alternative universe. In practice, a large fraction of build probes are broken. OK ... so I had one of those bad brain days after the dog woke me up at 4:30 this morning. And I finally gave up after lunch and just let ADHD-brain choose what to focus on for the afternoon. So - _challenge accepted_ (it just felt interesting and impossible is always motivator) I think I have a solution with: - a set of truly safe build probes (for a few select features) - which follows the opt-in approach of optional whitelisting that rustc & cargo both use (opt-in 1 to unstable, then opt-in 2 to granular opt-ins, then opt-in 3 to individual features) - respecting cargo `unstable.allow-features` & `RUSTFLAGS="-Zallow-features"` - in a way which promotes good practices and makes short-cuts very hard I would be genuinely interested (as much from an intellectual point of view than anything else) as to whether this is clearly still broken or flaky? I expect to spot one or two typos & errors in the "easy stuff" tomorrow, but I think the hard stuff is good... > [Previous page](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393.md?page=1) [Next page](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393.md?page=3)