The first parse is to collect whether the code contains macros, has
`main`, and uses other crates. In that pass we ignore errors as those
will be reported when the test file is actually built.
For that we need to reset errors in the `Diagnostic` otherwise when
dropping it unhandled errors will be reported as compiler bugs.
Fixes#80992
- 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.
It's not an internal lint:
- It's not in the rustc::internal lint group
- It's on unconditionally, because it actually lints `staged_api`, not
the compiler
This fixes a bug where `#[deny(rustc::internal)]` would warn that
`rustc::internal` was an unknown lint.
Improve JS performance by storing length before comparing to it in loops
Since https://github.com/rust-lang/rust/pull/79052 is quite complicated to review, I suggested to split into smaller parts. This first part is mostly about saving the array length into a variable (I tried to not change anything else as much as possible 😃 ).
r? `@jyn514`
Add test for #59352
Issue #59352 reported an optimization regression with rustc 1.32.0+. That regression could be tracked to a change that caused a function to miss the size limit of llvm's inlining, which results in an unreachable panicing branch being generated.
Enabling mir inline solves the issue, but is currently only done for `mir-opt-level>=2`.
This PR adds a test that can serve as a regression test for #59352, if/when mir inlining gets mature enough for opt-level 1, or some other optimization can remove the panic.
Remove DepKind::CrateMetadata and pre-allocation of DepNodes
Remove much of the special-case handling around crate metadata
dependency tracking by replacing `DepKind::CrateMetadata` and the
pre-allocation of corresponding `DepNodes` with on-demand invocation
of the `crate_hash` query.
Previously, clippy (and any other tool emitting lints) had to have their
own separate UNKNOWN_LINTS pass, because the compiler assumed any tool
lint could be valid. Now, as long as any lint starting with the tool
prefix exists, the compiler will warn when an unknown lint is present.
Choose the version of python at runtime (portable version)
r? `@Mark-Simulacrum`
Fixed version of https://github.com/rust-lang/rust/pull/80585. The goal is to avoid giving 'error: python3 required' when downloading LLVM from CI and instead default to python3 where possible.
This has some minor overhead when you have `python` as python2, but almost nothing compared to actually running the build.
