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.

…extern prelude

Newly stable API:

```rust
impl CStr {
    pub fn count_bytes(&self) -> usize;
}
```

Const stabilization has not yet been decided, so that will continue to be
gated under <rust-lang#113219>.

Fixes: <rust-lang#114441>

Unify the output of `suggest_assign_value` and `ty_kind_suggestion`.

Ideally we'd make these a single function, but doing so would likely require modify the crate dependency tree.

When suggesting a type on inference error, do not use `{closure@..}`.
Instead, replace with an appropriate `fn` ptr.

On the error message, use `short_ty_string` and write long types to
disk.

```
error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>`
  --> crates/lang/src/parser.rs:41:13
   |
41 |         let lit = select! {
   |             ^^^
42 |             Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
   |                                                                                                  ---- type must be known at this point
   |
   = note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt'
   = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
   |
41 |         let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! {
   |                +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```

instead of

```
error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>`
  --> crates/lang/src/parser.rs:41:13
   |
41 |         let lit = select! {
   |             ^^^
42 |             Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
   |                                                                                                  ---- type must be known at this point
   |
   = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
   |
41 |         let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! {
   |                ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```

Fix rust-lang#123630.

fixes rust-lang#120642

This reverts commit 049a917.

The resolution to <rust-lang#123282> is
that the `f16`/`f128` regression in the beta compiler was fixable
without a revert, so the commit adding `#[cfg(not(bootstrap))]` is no
longer useful (added in
<rust-lang#123390>).

Revert this commit because not having these basic impls bootstrap-gated
simplifies everything else that uses them.

Implement basic operation traits that get lowered to intrinsics. This
includes codegen tests for implemented operations.

Create empty modules so `rustdoc` has someplace to link to for these
types.

Add handling for `String`, `Box`, `Option` and `Result`.

…r=Amanieu

`f16` and `f128` step 4: basic library support

This is the next step after rust-lang#121926, another portion of rust-lang#114607

Tracking issue: rust-lang#116909

This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.

r? ``@Amanieu`` since you were pretty involved in the RFC
cc ``@compiler-errors``
``@rustbot`` label +T-libs-api +S-blocked +F-f16_and_f128

…r=petrochenkov

Be more specific when flagging imports as redundant due to the extern prelude

There are multiple distinct kinds of [preludes](https://doc.rust-lang.org/reference/names/preludes.html). Be more specific when flagging imports as redundant due to the [extern prelude](https://doc.rust-lang.org/reference/names/preludes.html#extern-prelude).

r? Nilstrieb or compiler

Skip `unused_parens` report for `Paren(Path(..))` in macro.

fixes rust-lang#120642

In following code, `unused_parens` suggest change `<($($rest),*)>::bar()` to `<$rest>::bar()`  which will cause another err: `error: variable 'rest' is still repeating at this depth`：

```rust
trait Foo {
    fn bar();
}

macro_rules! problem {
    ($ty:ident) => {
        impl<$ty: Foo> Foo for ($ty,) {
            fn bar() { <$ty>::bar() }
        }
    };
    ($ty:ident $(, $rest:ident)*) => {
        impl<$ty: Foo, $($rest: Foo),*> Foo for ($ty, $($rest),*) {
            fn bar() {
                <$ty>::bar();
                <($($rest),*)>::bar()
            }
        }
        problem!($($rest),*);
    }
}
```

I think maybe we can handle this by avoid warning for `Paren(Path(..))` in the macro. Is this reasonable approach?

…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``

…s, r=dtolnay

Stabilize `cstr_count_bytes`

Newly stable API:

```rust
impl CStr {
    pub fn count_bytes(&self) -> usize;
}
```

Const stabilization has not yet been decided, so that will continue to be gated under <rust-lang#113219>.

FCP finished at rust-lang#114441 (comment).

Fixes: <rust-lang#114441>

Use `fn` ptr signature instead of `{closure@..}` in infer error

When suggesting a type on inference error, do not use `{closure@..}`. Instead, replace with an appropriate `fn` ptr.

On the error message, use `short_ty_string` and write long types to disk.

```
error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>`
  --> crates/lang/src/parser.rs:41:13
   |
41 |         let lit = select! {
   |             ^^^
42 |             Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
   |                                                                                                  ---- type must be known at this point
   |
   = note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt'
   = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
   |
41 |         let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! {
   |                +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```

instead of

```
error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>`
  --> crates/lang/src/parser.rs:41:13
   |
41 |         let lit = select! {
   |             ^^^
42 |             Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
   |                                                                                                  ---- type must be known at this point
   |
   = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
   |
41 |         let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! {
   |                ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```

Address rust-lang#123630 (test missing).

…errors

Tweak value suggestions in `borrowck` and `hir_analysis`

Unify the output of `suggest_assign_value` and `ty_kind_suggestion`.

Ideally we'd make these a single function, but doing so would likely require modify the crate dependency tree.