…plied at the crate level.

When `no_builtins` is applied at the crate level, we should add the
`no-builtins` attribute to each function to ensure it takes effect in LTO.

…fill character

…errors

add tests for alias bound preference

cc rust-lang/trait-system-refactor-initiative#45

r? ``@compiler-errors``

…, r=pnkfelix

Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.

**When `no_builtins` is applied at the crate level, we should add the `no-builtins` attribute to each function to ensure it takes effect in LTO.**

This is also the reason why no_builtins does not take effect in LTO as mentioned in rust-lang#35540.

Now, `#![no_builtins]` should be similar to `-fno-builtin` in clang/gcc, see https://clang.godbolt.org/z/z4j6Wsod5.

Next, we should make `#![no_builtins]` participate in LTO again. That makes sense, as LTO also takes into consideration function-level instruction optimizations, such as the MachineOutliner. More importantly, when a user writes a large `#![no_builtins]` crate, they would like this crate to participate in LTO as well.

We should also add a function-level no_builtins attribute to allow users to have more control over it. This is similar to Clang's `__attribute__((no_builtin))` feature, see https://clang.godbolt.org/z/Wod6KK6eq. Before implementing this feature, maybe we should discuss whether to support more fine-grained control, such as `__attribute__((no_builtin("memcpy")))`.

Related discussions:
- rust-lang#109821
- rust-lang#35540

Next (a separate pull request?):
- [ ] Revert rust-lang#35637
- [ ] Add a function-level `no_builtin` attribute?

…chenkov

Simplify native_libs query

Drive-by cleanup I saw while implementing rust-lang#113734

Make it clearer that edition functions are `>=`, not `==`

r? `@Nilstrieb`

We could also perhaps derive `Ord` on `Edition` and use comparison operators.

… r=eholk

Improve error message when closing bracket interpreted as formatting fill character

Fixes rust-lang#112732 by explaining why it's erroring in the way it is.

…-105735-fix, r=notriddle,aDotInTheVoid

Fix invalid display of inlined re-export when both local and foreign items are inlined

Fixes rust-lang#105735.

The bug is actually quite interesting: at the `clean` pass, local inlined items have their `use` item removed, however foreign items don't have their `use` item removed because it's in the `clean` pass that we handle them. So when a `use` inlines both a local and a foreign item, it will work as expected for the foreign one, but not for the local as its `use` should not be around anymore.

To prevent this, I created a new `inlined_foreigns` field into the `Module` struct to allow to remove the `use` item early on for foreign items as well. Then we iterate it in the `clean` pass directly.

r? ``@notriddle``

…, r=fee1-dead

Fix inline_const with interpolated block

Interpolation already worked when we had a `const $block` that wasn't a statement expr:

```
fn foo() {
  let _ = const $block;
}
```

But it was failing when the const block was in statement expr position:

```
fn foo() {
  const $block;
}
```

... because of a bug in a check for const items. This fixes that.

---

cc rust-lang#112953 (comment), though I don't think this requires an FCP since it's already supported in exprs and seems to me to be fully a parser bug.