Open ehuss opened 5 years ago
If we expose some control over this, I think it will be limited to #[cfg(feature = "…")]
like in "normal" dependency crates, not arbitrary #[cfg(…)]
like the issue title and description suggest.
If we expose some control over this, I think it will be limited to …
Yes, that is what I meant. I think this originally started as a broader thought about portability issues (cfg
being influenced by target settings and rustc
flags), but I didn't update the title when I narrowed it down.
Use case: Opt-in support for having RefCell
capture backtraces for outstanding borrows, and print them when borrow()
/borrow_mut()
panics. See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for more details
I'm not sure if this is intended or accidental (i didn't see it mentioned in unstable docs or cargo test suite) but it is currently possible to specify features on libcore directly, like this : -Z build-std=std -Z build-std-features=core/debug_refcell
.
In the case of debug_refcell
it is actually usefull, because this feature is currently not forwarded by libstd and libtest, so just using -Z build-std-features=debug_refcell
will not work
This is a "use case" issue to try to clarify and discuss a use case, and how it will be addressed.
There has been some interest in being able to pass different cargo feature flags to the standard library to change it some way; either to change the implementation, or to disable sections of the library.
This is unlikely to be possible with Cargo's current features system. There are some problems with backwards-compatibility, and generally the level of commitment to stabilize a feature flag would likely be extremely high.
Please leave a comment if you have any specific use cases to consider. Some that have come up in the past:
force-tiny-fmt
to use a different algorithm forfmt
.std
already has a number of cargo features (panic, backtrace, profiler, etc.).backtrace
can maybe be helpful in reducing binary size?This issue is to explore possible features, how they can be expressed from Cargo, and whether or not it is feasible to accomplish in a stable way.
This is partially related to #8.