Stop exporting `TypeckRootCtxt` and `FnCtxt`.
While they have many convenient APIs, it is better to expose dedicated functions for them
noticed in #122213
Add consistency with phrases "meantime" and "mean time"
"mean time" is used in a few places while "meantime" is used everywhere else; this would make usage consistent throughout the codebase.
The actual ABI implication here is that in some cases the values
are required to be "consecutive", i.e. must either all be passed
in registers or all on stack (without padding).
Adjust the code to either use Uniform::new() or Uniform::consecutive()
depending on which behavior is needed.
Then, when lowering this in LLVM, skip the [1 x i128] to i128
simplification if is_consecutive is set. i128 is the only case
I'm aware of where this is problematic right now. If we find
other cases, we can extend this (either based on target information
or possibly just by not simplifying for is_consecutive entirely).
When passing a 16 (or higher) aligned struct by value on ppc64le,
it needs to be passed as an array of `i128` rather than an array
of `i64`. This will force the use of an even starting register.
For the case of a 16 byte struct with alignment 16 it is important
that `[1 x i128]` is used instead of `i128` -- apparently, the
latter will get treated similarly to `[2 x i64]`, not exhibiting
the correct ABI. Add a `force_array` flag to `Uniform` to support
this.
The relevant clang code can be found here:
fe2119a7b0/clang/lib/CodeGen/Targets/PPC.cpp (L878-L884)fe2119a7b0/clang/lib/CodeGen/Targets/PPC.cpp (L780-L784)
I think the corresponding psABI wording is this:
> Fixed size aggregates and unions passed by value are mapped to as
> many doublewords of the parameter save area as the value uses in
> memory. Aggregrates and unions are aligned according to their
> alignment requirements. This may result in doublewords being
> skipped for alignment.
In particular the last sentence.
Fixes https://github.com/rust-lang/rust/issues/122767.
This particular cast appears to have been copied over from clang, but there are
plenty of other call sites in clang that don't bother with a cast here, and it
works fine without one.
For context, `llvm::Intrinsic::ID` is a typedef for `unsigned`, and
`llvm::Intrinsic::instrprof_increment` is a member of
`enum IndependentIntrinsics : unsigned`.
Save/restore more items in cache with incremental compilation
Right now they don't play very well together, consider a simple example:
```
$ export RUSTFLAGS="--emit asm"
$ cargo new --lib foo
Created library `foo` package
$ cargo build -q
$ touch src/lib.rs
$ cargo build
error: could not copy
"/path/to/foo/target/debug/deps/foo-e307cc7fa7b6d64f.4qbzn9k8mosu50a5.rcgu.s"
to "/path/to/foo/target/debug/deps/foo-e307cc7fa7b6d64f.s":
No such file or directory (os error 2)
```
Touch triggers the rebuild, incremental compilation detects no changes (yay) and everything explodes while trying to copy files were they should go.
This pull request fixes it by copying and restoring more files in the incremental compilation cache
Fixes https://github.com/rust-lang/rust/issues/89149
Fixes https://github.com/rust-lang/rust/issues/88829
Related: https://internals.rust-lang.org/t/interaction-between-incremental-compilation-and-emit/20551
Fix incorrect 'llvm_target' value used on watchOS target
## Issue
`xcodebuild -create-xcframework` command doesn't recognize static libraries that are built on "arm64_32-apple-watchos" target.
Here are steps to reproduce the issue on a Mac:
1. Install nightly toolchain `nightly-2024-03-27`. Needs this specific version, because newer nightly versions are broken on watchos target.
1. Create an empty library: `mkdir watchos-lib && cd watchos-lib && cargo init --lib`.
1. Add configuration `lib.crate-type=["staticlib"]` to Cargo.toml.
1. Build the library: `cargo +nightly-2024-03-27 build --release -Zbuild-std --target arm64_32-apple-watchos`
1. Run `xcodebuild -create-xcframework` to put the static library into a xcframework, which results in an error:
```
$ xcodebuild -create-xcframework -library target/arm64_32-apple-watchos/release/libwatchos_lib.a -output test.xcframework
error: unable to determine the platform for the given binary '.../watchos-lib/target/arm64_32-apple-watchos/release/libwatchos_lib.a'; check your deployment version settings
```
## Fix
The root cause of this error is `xcodebuild` couldn't read `LC_BUILD_VERSION` from the static library to determine the library's target platform. And the reason it's missing is that an incorrect `llvm_target` value is used in `arm64_32-apple-watchos` target. The expected value is `<arch>-apple-watchos<major>.<minor>.0`, i.e. "arm64_32-apple-watchos8.0.0".
The [.../apple/mod.rs](43f4f2a3b1/compiler/rustc_target/src/spec/base/apple/mod.rs (L321)) file contains functions that construct such string. There is an existing function `watchos_sim_llvm_target` which returns llvm target value for watchOS simulator. But there is none for watchOS device. This PR adds that missing function to align watchOS with other Apple platform targets.
To verify the fix, you can simply build a toolchain on this PR branch and repeat the steps above using the built local toolchain to verify the `xcodebuild -create-xcframework` command can create a xcframework successfully.
Furthermore, you can verify `LC_BUILD_VERSION` contains correct info by using the simple shell script below to print `LC_BUILD_VERSION` of the static library that's built on watchos target:
```shell
bin=target/arm64_32-apple-watchos/release/libwatchos_lib.a
file=$(ar -t "$bin" | grep -E '\.o$' | head -n 1)
ar -x "$bin" "$file"
vtool -show-build-version "$file"
```
Here is an example output from my machine:
```
watchos_rust-495d6aaf3bccc08d.watchos_rust.35ba42bf9255ca9d-cgu.0.rcgu.o:
Load command 1
cmd LC_BUILD_VERSION
cmdsize 24
platform WATCHOS
minos 8.0
sdk n/a
ntools 0
```
Remove sharding for VecCache
This sharding is never used (per the comment in code). If we re-add sharding at some point in the future this is cheap to restore, but for now no need for the extra complexity.
Add a debug asserts call to match_projection_projections to ensure invariant
Small nit as follow up of #123471.
r? `@compiler-errors`
`@bors` rollup=always
This sharding is never used (per the comment in code). If we re-add
sharding at some point in the future this is cheap to restore, but for
now no need for the extra complexity.
Rollup of 7 pull requests
Successful merges:
- #123294 (Require LLVM_CONFIG to be set in rustc_llvm/build.rs)
- #123467 (MSVC targets should use COFF as their archive format)
- #123498 (explaining `DefKind::Field`)
- #123519 (Improve cfg and check-cfg configuration)
- #123525 (CFI: Don't rewrite ty::Dynamic directly)
- #123526 (Do not ICE when calling incorrectly defined `transmute` intrinsic)
- #123528 (Hide async_gen_internals from standard library documentation)
r? `@ghost`
`@rustbot` modify labels: rollup
CFI: Don't rewrite ty::Dynamic directly
Now that we're using a type folder, the arguments in predicates are processed automatically - we don't need to descend manually.
We also want to keep projection clauses around, and this does so.
r? `@compiler-errors`
Improve cfg and check-cfg configuration
This PR improves cfg and check-cfg configuration by:
1. Extracting both logic under a common module (to improve the connection between the two)
2. Adding more documentation, in particular some steps when adding a new cfg
I also added my-self as mention in our triagebot conf for the new module.
Inspired by https://github.com/rust-lang/rust/pull/123411#discussion_r1554056681
MSVC targets should use COFF as their archive format
While adding support for Arm64EC I ran into an issue where the standard library's rlib was missing the "EC Symbol Table" which is required for the MSVC linker to find import library symbols (generated by Rust's `raw-dylib` feature) when building for EC.
The root cause of the issue is that LLVM only generated symbol tables (including the EC Symbol Table) if the `ArchiveKind` is `COFF`, but the MSVC targets didn't set their archive format, so it was defaulting to GNU.
Require LLVM_CONFIG to be set in rustc_llvm/build.rs
This environment variable should always be set by bootstrap in `rustc_llvm_env`. The fallback is quite ugly and complicated, so removing it is nice.
bf71daedc2/src/bootstrap/src/core/build_steps/compile.rs (L1166)
I tried finding when this was added in git history, but it pointed all the way to "add build scripts" at which point I stopped digging more. This has always been here.
cc `@nikic` `@cuviper` in case you happen to be aware of a deeper reason behind this
r? bootstrap
Check def id before calling `match_projection_projections`
When I "inlined" `assemble_candidates_from_predicates` into `for_each_item_bound` in #120584, I forgot to copy over the check that actually made sure the def id of the candidate was equal to the def id of the obligation. This means that we normalize goal a bit too often even if it's not productive to do so.
This PR adds that def id check back.
Fixes#123448
Now that we're using a type folder, the arguments in predicates are
processed automatically - we don't need to descend manually.
We also want to keep projection clauses around, and this does so.
