The restricted_std error message is confusing #87

ehuss · 2023-05-03T23:45:46Z

If you attempt to build a no-std target, and you forget to include #![no_std] (or you forget to remove a std feature in a dependency, or use a std-needing dependency), then it results in a fairly confusing error:

error[E0658]: use of unstable library feature 'restricted_std'
  |
  = help: add `#![feature(restricted_std)]` to the crate attributes to enable

I think that will be a frequent error that will be challenging for users to understand.

I don't know how to address that. It might be nice if cargo could know whether or not a target is intended to support "std", but that sounds challenging.

The text was updated successfully, but these errors were encountered:

This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't. This commit fixes rust-lang/wg-cargo-std-aware#87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see rust-lang#27242 rust-lang#103765). Note that the message says "platform" and "environment" because, since rust-lang#120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable rust-lang/wg-cargo-std-aware#90), but a JSON target with the right configuration should hopefully have some partial libstd support. I propose closing rust-lang/wg-cargo-std-aware#69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time. The alternative to closing rust-lang/wg-cargo-std-aware#69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std.

…d-std, r=ehuss Document restricted_std This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't. This commit fixes rust-lang/wg-cargo-std-aware#87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see rust-lang#27242 rust-lang#103765). Note that the message says "platform" and "environment" because, since rust-lang#120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable rust-lang/wg-cargo-std-aware#90), but a JSON target with the right configuration should hopefully have some partial libstd support. I propose closing rust-lang/wg-cargo-std-aware#69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time. The alternative to closing rust-lang/wg-cargo-std-aware#69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std. cc `@ehuss`

…d-std, r=ehuss Document restricted_std This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't. This commit fixes rust-lang/wg-cargo-std-aware#87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see rust-lang#27242 rust-lang#103765). Note that the message says "platform" and "environment" because, since rust-lang#120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable rust-lang/wg-cargo-std-aware#90), but a JSON target with the right configuration should hopefully have some partial libstd support. I propose closing rust-lang/wg-cargo-std-aware#69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time. The alternative to closing rust-lang/wg-cargo-std-aware#69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std. cc ``@ehuss``

…d-std, r=ehuss Document restricted_std This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't. This commit fixes rust-lang/wg-cargo-std-aware#87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see rust-lang#27242 rust-lang#103765). Note that the message says "platform" and "environment" because, since rust-lang#120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable rust-lang/wg-cargo-std-aware#90), but a JSON target with the right configuration should hopefully have some partial libstd support. I propose closing rust-lang/wg-cargo-std-aware#69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time. The alternative to closing rust-lang/wg-cargo-std-aware#69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std. cc ```@ehuss```

Rollup merge of rust-lang#123360 - adamgemmell:dev/adagem01/restricted-std, r=ehuss Document restricted_std This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't. This commit fixes rust-lang/wg-cargo-std-aware#87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see rust-lang#27242 rust-lang#103765). Note that the message says "platform" and "environment" because, since rust-lang#120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable rust-lang/wg-cargo-std-aware#90), but a JSON target with the right configuration should hopefully have some partial libstd support. I propose closing rust-lang/wg-cargo-std-aware#69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time. The alternative to closing rust-lang/wg-cargo-std-aware#69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std. cc ```@ehuss```

…tadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745

…metadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745

…tadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745

…=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: #120745

ehuss added plan before stabilization This needs a plan for how to address before stabilization, but does not need to be implemented. S-needs-design Status: needs design work labels May 3, 2023

mohe2015 mentioned this issue Jan 3, 2024

How to activate unstable feature restricted_std in rust-analyzer? rust-lang/rust-analyzer#16232

Closed

adamgemmell mentioned this issue Apr 2, 2024

Document restricted_std rust-lang/rust#123360

Merged

This was referenced Jul 3, 2024

Fill out target-spec metadata for all targets rust-lang/rust#127265

Merged

Check build target supports std when building with -Zbuild-std=std rust-lang/cargo#14183

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The restricted_std error message is confusing #87

The restricted_std error message is confusing #87

ehuss commented May 3, 2023

The restricted_std error message is confusing #87

The restricted_std error message is confusing #87

Comments

ehuss commented May 3, 2023