{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib5nakmios73nvax2vmudxyply6wywhzvrjfq5vtv5dp3wrrgw7bi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mphnow4bjao2"
  },
  "path": "/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393?page=2#post_34",
  "publishedAt": "2026-06-29T18:15:31.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "↩︎"
  ],
  "textContent": "Nemo157:\n\n> Did you try when set via `CARGO_UNSTABLE_ALLOW_FEATURES` too?\n\nYep - 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)\n\nNemo157:\n\n> 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\n\nIf 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\")\n\n* * *\n\n  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 ↩︎\n\n\n",
  "title": "Code compiles on playground but fails when passed via stdin to rustc"
}