Prevent constant rebuilds of `rustc-main` (and thus everything else)
PR #114305 changed bootstrap to run `strip -g` on `librustc_driver.so` and `libllvm.so` on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1 `rustc-main` (including stage 1 libraries and tests) when invoking bootstrap multiple times.
We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running `./x build library/sysroot --stage 1` twice.
The explanation of the problem is in the code comments.
r? ```@lqd```
cc ```@ozkanonur```
add aarch64-unknown-teeos target
TEEOS is a mini os run in TrustZone, for trusted/security apps. The libc of TEEOS is a part of musl. The kernel of TEEOS is micro kernel.
This MR is to add a target for teeos.
MRs for libc and rust-std are in progress.
Compiler team MCP: [MCP](https://github.com/rust-lang/compiler-team/issues/652)
Rename method in `opt-dist`
This makes it clearer that the LLVM is the host one (it doesn't necessarily have to be downloaded). On Linux, it comes from the Dockerfile, on Windows it's downloaded.
Suggested here: https://github.com/rust-lang/rust/pull/114344#discussion_r1285596217
r? `@lqd`
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes#114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
Update to LLVM 17
Expected LLVM 17.0.0 release date: Sep 5th
Rust 1.73 release date: Oct 5th
Compatibility changes in this PR:
- Drop LLVM_RUSTLLVM check for target-cpu table, which no longer requires a patch with LLVM 17.
- Update powerpc data layouts, which now include function alignment information. As usual, downgrade for older LLVM versions.
- Adjust the stack-protector.rs test so that the stack smashing does not get optimized away.
- Adjust path of crtbegin.c and crtend.c in compiler-rt.
- Updated dist-riscv64-linux to use binutils 2.36 in order to recognize the zicsr feature, which is no longer part of the base ISA.
- Fixed symlink for asm include directory on dist-various-2. We should use `/usr/include/x86_64-linux-gnu/asm` for the host, rather than `/usr/include/asm-generic`.
Upstream patches:
- [x] https://reviews.llvm.org/D156525 (backported)
Perf run: https://perf.rust-lang.org/compare.html?start=f239bb6bea94d16d902c36d72b5cabdddefb3cab&end=8030d71a95a3ea79f5fc95232c32f9b78effb92d&stat=instructions:uFixes#109671.
Successful: dist-x86_64-linux, dist-aarch64-linux, dist-s390x-linux, dist-powerpc-linux, armhf-gnu, wasm32
We should symlink /usr/include/x86_64-linux-gnu/asm for the host
triple, rather than /usr/include/asm-generic, which is used in the
implementation for asm for specific triple, but shouldn't be used
by itself.
CI: do not hide error logs in a group
This PR avoids creating a GHA group at the very end of a CI workflow when some failure has happened. Before, when a failure has happened, its GHA group was not closed, however the clock drift check function would create a new group, which would actually close the group containing the error log, thus making errors hidden by default, which is not ideal.
See discussion here: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/GHA.20groups.20being.20closed.20on.20failures
r? bootstrap
Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly
As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target. (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)
Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.
cc `@RalfJung` `@Amanieu`
fix(ci): Ensure idempotence of user creation
Previously, re-running `run.sh` in the same container would fail at the useradd step, because the user already exists. Instead, change that step to "create if not exists" semantics to ease interactive debugging of CI failures.
Split out from https://github.com/rust-lang/rust/pull/111891 per request by `@jackh726`
Add more context to `quit_if_file_exists` in `configure.py` & delete config.toml in CI
If the `obj` directory isn't empty, the error message is subtle and not very helpful:
```
== clock drift check ==
local time: Sun Jul 2 00:57:06 UTC 2023
network time: Sun, 02 Jul 2023 00:57:06 GMT
== end clock drift check ==
sccache: Starting the server...
configure: error: Existing 'config.toml' detected.
== clock drift check ==
local time: Sun Jul 2 00:57:06 UTC 2023
network time: Sun, 02 Jul 2023 00:57:06 GMT
== end clock drift check ==
```
This makes it stand out and suggests how to resolve the issue:
```
== clock drift check ==
local time: Sun Jul 2 02:11:30 UTC 2023
network time: Sun, 02 Jul 2023 02:11:31 GMT
== end clock drift check ==
sccache: Starting the server...
configure: ERROR: Existing 'config.toml' detected. Exiting
Is objdir '/home/tmgross/projects/rust/obj' clean?
== clock drift check ==
local time: Sun Jul 2 02:11:31 UTC 2023
network time: Sun, 02 Jul 2023 02:11:31 GMT
== end clock drift check ==
```
Add documentation to has_deref
Documentation of `has_deref` needed some polish to be more clear about where it should be used and what's it's purpose.
cc https://github.com/rust-lang/rust/issues/114401
r? `@RalfJung`
It was added by 77971 but the adder proposed in that PR that the added
code is a good fallback to have in case rustdoc gets buggy, and I agree.
So remove the FIXME.
Rename tests/ui/issues/issue-100605.rs to ../type/option-ref-advice.rs
The test is a regression test for a [bug ](https://github.com/rust-lang/rust/issues/100605) where the compiler gave bad advice for an `Option<&String>`. Rename the file appropriately.
Part of #73494
Convert builtin "global" late lints to run per module
The compiler currently has 4 non-incremental lints:
1. `clashing_extern_declarations`;
2. `missing_debug_implementations`;
3. ~`unnameable_test_items`;~ changed by https://github.com/rust-lang/rust/pull/114414
4. `missing_docs`.
Non-incremental lints get reexecuted for each compilation, which is slow. Moreover, those lints are allow-by-default, so run for nothing most of the time. This PR attempts to make them more incremental-friendly.
`clashing_extern_declarations` is moved to a standalone query.
`missing_debug_implementation` can use `non_blanket_impls_for_ty` instead of recomputing it.
`missing_docs` is harder as it needs to track if there is a `doc(hidden)` module surrounding. I hack around this using the lint level engine. That's easy to implement and allows to re-enable the lint for a re-exported module, while a more proper solution would reuse the same device as `unnameable_test_items`.
Fix ui-fulldeps missing the `internal_features` lint on stage 0
Similar to #114102, `ui-fulldeps --stage=1` builds using the the stage 0 compiler instead of the stage 1 compiler. That means that the new `internal_features` lint is referencing a lint that does not exist. Gate the flag it properly until the next feature bump.
Maybe we should just add ui-fulldeps stage 1 into CI somewhere so this is flagged before landing.
