Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build the standard library with different cargo features #4

Open
ehuss opened this issue Jul 20, 2019 · 5 comments
Open

Build the standard library with different cargo features #4

ehuss opened this issue Jul 20, 2019 · 5 comments
Labels
use case Discussion on a high-level use case

Comments

@ehuss
Copy link
Contributor

ehuss commented Jul 20, 2019

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:

  • The RFC 2663 proposal had a suggestion of force-tiny-fmt to use a different algorithm for fmt.
  • std already has a number of cargo features (panic, backtrace, profiler, etc.).
    • Removing things like 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.

@ehuss ehuss added the use case Discussion on a high-level use case label Jul 20, 2019
@SimonSapin
Copy link

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.

@ehuss ehuss changed the title Build the standard library with different cfg settings Build the standard library with different cargo features Jul 23, 2019
@ehuss
Copy link
Contributor Author

ehuss commented Jul 23, 2019

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.

@ehuss
Copy link
Contributor Author

ehuss commented Jul 24, 2020

An experimental flag has been added to control the features used: docs, PR

@Aaron1011
Copy link
Member

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

@macpp
Copy link

macpp commented Feb 20, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
use case Discussion on a high-level use case
Projects
None yet
Development

No branches or pull requests

4 participants