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

**URL:** <https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393>\
**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:** 2\
**Page:** 3

<div class="post-metadata">

**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:** [July 1, 2026, 9:18pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/41 "2026-07-01T21:18:47Z")

</div>

My first thought would be "what directory is that `cargo config` executing under?", I would kind of expect build-script-run to use the manifest-dir of the defining crate, while the config you care about is the top-level build.

EDIT: which leads into the second question: "if this is cached and reused for a different build with a different config, how does it invalidate the cache?" (since there's no `rerun-if-changed` for `cargo config`).

---

<div class="post-metadata">

**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 2, 2026, 5:21pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393/42 "2026-07-02T17:21:33Z")

</div>

> [@Nemo157](#):
>
> My first thought would be "what directory is that `cargo config` executing under?", I would kind of expect build-script-run to use the manifest-dir of the defining crate, while the config you care about is the top-level build.

My assumption was the current working directory where cargo build/test/run was invoked. You were right, and I found it in the cargo docs after manually debugging via one of my other crates.

Thanks for the tip.

The best solution I could come up with is\[1\]:

> - This will obtain config.toml files based upon `OUT_DIR`. If this is not under the project root, you can override by providing an alternative path via the environment variable `NINJA_CARGO_CONFIG_DIR`. See cargo’s documentation on config file hierarchical structure for more details.

To my view that now respects the standard expectations of the cumulative opt-in approach taken by `rustc` & `cargo`:

1. opt-in to unstable features via toolchain (all features available)
2. opt-in to granular opt-in by specifying allow-features (empty whitelist - no features available)
3. opt-in to specific features (only whitelisted features available)

> [@Nemo157](#):
>
> EDIT: which leads into the second question: "if this is cached and reused for a different build with a different config, how does it invalidate the cache?" (since there's no `rerun-if-changed` for `cargo config`).

If you have a suitable trigger for this I'd be happy to add it. How do you trigger a rebuild of your own crate when you update any of the relevant `config.toml`s`? - the config change is potentially equally relevant there...

* * *

1. both documented in the crate docs under "Note to downstream crates" and designed to be obvious in the code

[Previous page](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393.md?page=2)