It overwrites the definition from rustc_metadata

- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked
statically
- Add `link-type.txt` so bootstrap knows whether llvm was linked
  statically or dynamically
- Don't assume CI LLVM is linked dynamically in `bootstrap::config`
- Fall back to dynamic linking if `link-type.txt` doesn't exist
- Fix existing bug that split the output of `llvm-config` on lines, not spaces
- Enable building LLVM tests

  This works around the following llvm bug:

  ```
  llvm-config: error: component libraries and shared library

  llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a
  llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a
  llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a
  thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles"
  ```

  I'm not sure why llvm-config thinks these are required, but to avoid
  the error, this builds them anyway.

- Temporarily set windows as the try builder. This should be reverted
  before merging.

- Bump version of `download-ci-llvm-stamp`

  `src/llvm-project` hasn't changed, but the generated tarball has.

- Only special case MacOS when dynamic linking. Static linking works fine.
- Store `link-type.txt` to the top-level of the tarball

  This allows writing the link type unconditionally. Previously, bootstrap
  had to keep track of whether the file IO *would* succeed (it would fail
  if `lib/` didn't exist), which was prone to bugs.

- Make `link-type.txt` required

  Anyone downloading this from CI should be using a version of bootstrap
  that matches the version of the uploaded artifacts. So a missing
  link-type indicates a bug in x.py.

... and update the comment in `config.toml.example`

Fixes rust-lang#81006

This saves instructions on both new and old machines.

correctly deal with late-bound lifetimes in anon consts

adds support for using late bound lifetimes of the parent context in anon consts.
```rust
#![feature(const_generics)]
const fn inner<'a>() -> usize where &'a (): Sized { 3 }

fn test<'a>() {
    let _: [u8; inner::<'a>()];
}
```
The lifetime `'a` is late bound in `test` so it's not included in its generics but is instead dealt with separately in borrowck.
This didn't previously work for anon consts as they have to use the late bound lifetimes of their parent which has
to be explicitly handled.

r? ``@matthewjasper`` cc ``@varkor`` ``@eddyb``

resolve: Reject ambiguity built-in attr vs different built-in attr

Fixes rust-lang#79798.

Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.

…drAus

Add benchmark and fast path for BufReader::read_exact

At work, we have a wrapper type that implements this optimization. It would be nice if the standard library were faster.

Before:
```
test io::buffered::tests::bench_buffered_reader_small_reads       ... bench:       7,670 ns/iter (+/- 45)
```
After:
```
test io::buffered::tests::bench_buffered_reader_small_reads       ... bench:       4,457 ns/iter (+/- 41)
```

…mbol, r=nikomatsakis`

Improve diagnostics when closure doesn't meet trait bound

Improves the diagnostics when closure doesn't meet trait bound by modifying `TypeckResuts::closure_kind_origins` such that `hir::Place` is used instead of `Symbol`. Using `hir::Place` to describe which capture influenced the decision of selecting a trait a closure satisfies to (Fn/FnMut/FnOnce, Copy) allows us to show precise path in the diagnostics when `capture_disjoint_field` feature is enabled.

Closes rust-lang/project-rfc-2229/issues/21

r? ``@nikomatsakis``

…ewjasper

resolve: Simplify collection of traits in scope

"Traits in scope" for a given location are collected by walking all scopes in type namespace, collecting traits in them and pruning traits that don't have an associated item with the given name and namespace.

Previously we tried to prune traits using some kind of hygienic resolution for associated items, but that was complex and likely incorrect, e.g. in rust-lang#80762 correction to visibilites of trait items caused some traits to not be in scope anymore.
I previously had some comments and concerns about this in rust-lang#65351.

In this PR we are doing some much simpler pruning based on `Symbol` and `Namespace` comparisons, it should be enough to throw away 99.9% of unnecessary traits.
It is not necessary for pruning to be precise because for trait aliases, for example, we don't do any pruning at all, and precise hygienic resolution for associated items needs to be done in typeck anyway.

The somewhat unexpected effect is that trait imports introduced by macros 2.0 now bring traits into scope due to the removed hygienic check on associated item names.
I'm not sure whether it is desirable or not, but I think it's acceptable for now.
The old check was certainly incorrect because macros 2.0 did bring trait aliases into scope.
If doing this is not desirable, then we should come up with some other way to avoid bringing traits from macros 2.0 into scope, that would accommodate for trait aliases as well.

---

The PR also contains a couple of pure refactorings
- Scope walk is done by using `visit_scopes` instead of a hand-rolled version.
- Code is restructured to accomodate for rustdoc that also wants to query traits in scope, but doesn't want to filter them by associated items at all.

r? ``@matthewjasper``

…k-Simulacrum

Allow downloading LLVM on Windows and MacOS

- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked
statically
- Add `link-type.txt` so bootstrap knows whether llvm was linked
  statically or dynamically
- Don't assume CI LLVM is linked dynamically in `bootstrap::config`
- Fall back to dynamic linking if `link-type.txt` doesn't exist
- Fix existing bug that split the output of `llvm-config` on lines, not spaces
- Only special case MacOS when dynamic linking. Static linking works fine.
- Enable building LLVM tests

  This works around the following llvm bug:

  ```
  llvm-config: error: component libraries and shared library

  llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a
  llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a
  llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a
  thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles"
  ```

  I'm not sure why llvm-config thinks these are required, but to avoid
  the error, this builds them anyway.

- Bump version of `download-ci-llvm-stamp`

  `src/llvm-project` hasn't changed, but the generated tarball has.

Fixes rust-lang#77084.

# Current Status

This works on both MacOS and Windows! 🎉 🎉 Thanks to ``@nagisa,`` ``@halkcyon,`` ``@Lokathor,`` ``@jryans,`` and ``@poliorcetics`` for helping me test!

The `if-available` check now supports all tier 1 platforms. Although only x64 apple and x64 msvc have been tested, none of the changes here are Windows or Mac specific, and I expect this to work anywhere that LLVM artifacts are uploaded to CI (i.e. the `rust-dev` component exists).

## Windows

Note that if you have an old version of MSVC build tools you'll need to update them. VS Build Tools 2019 14.28 and later are known to work. With old tools, you may see an error like the following:

```
error LNK2001: unresolved external symbol __imp___std_init_once_complete
```

…item, r=nagisa

Remove is_dllimport_foreign_item definition from cg_ssa

It overwrites the definition from rustc_metadata.

cc https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/query.20provided.20twice/near/218927806

Marked as draft to test if this breaks anything.

…k, r=jyn514

Support non-stage0 check

Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail).

Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly.

r? ``@jyn514``

rustc_parse_format: Fix character indices in find_skips

Fixes rust-lang#81006

…ark-Simulacrum

BTreeMap: clean up a few more comments

And mark `pop` as unsafe.
r? ``@Mark-Simulacrum``

Use Option::map instead of open-coding it

r? ``@oli-obk``
``@rustbot`` modify labels +C-cleanup +T-compiler

Use Option::unwrap_or instead of open-coding it

r? ``@oli-obk`` Noticed this while we were talking about the other PR just now 😆
``@rustbot`` modify labels +C-cleanup +T-compiler

…=kennytm

Add NonZeroUn::is_power_of_two

This saves instructions on both new and old machines <https://rust.godbolt.org/z/4fjTMz>
- On the default x64 target (with no fancy instructions available) it saves a few instructions by not needing to also check for zero.
- On newer targets (with BMI1) it uses `BLSR` for super-short assembly.

This can be used for things like checks against alignments stored in `NonZeroUsize`.