allow_internal_unstable is currently used
to side-step feature gate and stability checks.
While it was originally only meant to be used
only on macros, its use was expanded to
const functions.

This commit prepares stricter checks for the usage of allow_internal_unstable (only on macros)
and introduces the rustc_allow_const_fn_unstable attribute for usage on functions.

See rust-lang#69399

…able

Adds a check to make sure `#[allow_internal_unstable]`
can be applied only to macro definitions.

Adds a check to make sure `#[rustc_allow_const_fn_unstable]`
can be applied only to functions.

Recognition for `rustc_allow_const_fn_unstable` attribute was errorneously
added in 05f4a9a.

…n rustc_mir

Followup rename from 05f4a9a,
which introduced `#[rustc_allow_const_fn_unstable]` for `const fn`s.

The validation was introduced in 3a63bf0
without strict validation of functions, e. g. all function types were
allowed.
Now the validation only allows `const fn`s.

…et docs

The `xargo` tool is in maintenance mode since 2018 and the `build-std` feature of cargo already works reasonably well for most use cases.

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>

When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR rust-lang#78306

Fixes rust-lang#75982

The direct parent of a module may not be a module
(e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`).

To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.

…t, r=petrochenkov

Compute proper module parent during resolution

Fixes rust-lang#75982

The direct parent of a module may not be a module
(e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`).

To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.

…nt, r=oli-obk

MIR validation should check `SwitchInt` values are valid for the type

Fixes rust-lang#75440

replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s

`#[allow_internal_unstable]` is currently used to side-step feature gate and stability checks.
While it was originally only meant to be used only on macros, its use was expanded to `const fn`s.

This pr adds stricter checks for the usage of `#[allow_internal_unstable]` (only on macros) and introduces the `#[rustc_allow_const_fn_unstable]` attribute for usage on `const fn`s.

This pr does not change any of the functionality associated with the use of `#[allow_internal_unstable]` on macros or the usage of `#[rustc_allow_const_fn_unstable]` (instead of `#[allow_internal_unstable]`) on `const fn`s (see rust-lang#69399 (comment)).

Note: The check for `#[rustc_allow_const_fn_unstable]` currently only validates that the attribute is used on a function, because I don't know how I would check if the function is a `const fn` at the place of the check. I therefore openend this as a 'draft pull request'.

Closes rust-lang#69399

r? @oli-obk

Update `compiler_builtins` to 0.1.36

So, the libc build with cargo's `build-std` feature emits a lot of warnings like:
```
 warning: a method with this name may be added to the standard library in the future
   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/int/udiv.rs:98:23
    |
98  |             q = n << (<$ty>::BITS - sr);
    |                       ^^^^^^^^^^^
...
268 |         udivmod_inner!(n, d, rem, u128)
    |         ------------------------------- in this macro invocation
    |
    = warning: once this method is added to the standard library, the ambiguity may cause an error or change in behavior!
    = note: for more information, see issue rust-lang#48919 <rust-lang/issues/48919>
    = help: call with fully qualified syntax `Int::BITS(...)` to keep using the current method
    = help: add `#![feature(int_bits_const)]` to the crate attributes to enable `num::<impl u128>::BITS`
    = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```

(You can find the full log in https://github.com/rust-lang/libc/runs/1283695796?check_suite_focus=true for example.)

0.1.36 contains rust-lang/compiler-builtins#332 so this version should remove this warning.

cc rust-lang/libc#1942

Bump backtrace-rs to enable Mach-O support on iOS.

Related to rust-lang/backtrace-rs#378. Fixes backtraces on iOS that were missing in Rust v1.47.0 after switching to gimli because it only enabled Mach-O support on macOS.

…alexcrichton

Link to cargo's `build-std` feature instead of `xargo` in custom target docs

The `xargo` tool is in maintenance mode since 2018 and the `build-std` feature of cargo already works reasonably well for most use cases.

…vel, r=Mark-Simulacrum

BTreeMap: stop mistaking node::MIN_LEN for a node level constraint

Correcting rust-lang#77612 that fell into the trap of assuming that node::MIN_LEN is an imposed minimum everywhere, and trying to make it much more clear it is an offered minimum at the node level.

r? @Mark-Simulacrum

…rochenkov

Split out statement attributes changes from rust-lang#78306

This is the same as PR rust-lang#78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior).

This shouldn't have any user-visible effects, so it can be landed without lang team discussion.

---------
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR rust-lang#78306