Implement minimal, internal-only pattern types in the type system
rebase of https://github.com/rust-lang/rust/pull/107606
You can create pattern types with `std::pat::pattern_type!(ty is pat)`. The feature is incomplete and will panic on you if you use any pattern other than integral range patterns. The only way to create or deconstruct a pattern type is via `transmute`.
This PR's implementation differs from the MCP's text. Specifically
> This means you could implement different traits for different pattern types with the same base type. Thus, we just forbid implementing any traits for pattern types.
is violated in this PR. The reason is that we do need impls after all in order to make them usable as fields. constants of type `std::time::Nanoseconds` struct are used in patterns, so the type must be structural-eq, which it only can be if you derive several traits on it. It doesn't need to be structural-eq recursively, so we can just manually implement the relevant traits on the pattern type and use the pattern type as a private field.
Waiting on:
* [x] move all unrelated commits into their own PRs.
* [x] fix niche computation (see 2db07f94f44f078daffe5823680d07d4fded883f)
* [x] add lots more tests
* [x] T-types MCP https://github.com/rust-lang/types-team/issues/126 to finish
* [x] some commit cleanup
* [x] full self-review
* [x] remove 61bd325da19a918cc3e02bbbdce97281a389c648, it's not necessary anymore I think.
* [ ] ~~make sure we never accidentally leak pattern types to user code (add stability checks or feature gate checks and appopriate tests)~~ we don't even do this for the new float primitives
* [x] get approval that [the scope expansion to trait impls](https://rust-lang.zulipchat.com/#narrow/stream/326866-t-types.2Fnominated/topic/Pattern.20types.20types-team.23126/near/427670099) is ok
r? `@BoxyUwU`
Rollup of 6 pull requests
Successful merges:
- #115984 (extending filesystem support for Hermit)
- #120144 (privacy: Stabilize lint `unnameable_types`)
- #122807 (Add consistency with phrases "meantime" and "mean time")
- #123089 (Add invariant to VecDeque::pop_* that len < cap if pop successful)
- #123595 (Documentation fix)
- #123625 (Stop exporting `TypeckRootCtxt` and `FnCtxt`.)
r? `@ghost`
`@rustbot` modify labels: rollup
Stop exporting `TypeckRootCtxt` and `FnCtxt`.
While they have many convenient APIs, it is better to expose dedicated functions for them
noticed in #122213
Documentation fix
Changed "It must not be an identical residual when interconversion is involved" to "The residual is not mandated to be identical when interconversion is involved." as the previous parenthetical appears to state that the residual is not permitted to be identical when interconversion is involved. However the intention of the original wording was to convey that the residual is not required to be identical when interconversion is involved, which makes more sense contextually.
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.
extending filesystem support for Hermit
Extending `std` to create, change and read a directory for Hermit.
Hermit is a tier 3 platform and this PR changes only files, wich are related to the tier 3 platform.
Do some preparation work for compiletest check-cfg
This PR does several preparation work for having always-on check-cfg in compiletest.
In particular, this PR does two main things:
- It unifies all the *always-false* cfgs under the `FALSE` cfg (as it seems to be the convention under `tests/ui`)
- It also removes some useless conditions
This is done ahead of the introduction of the always-on check-cfg in compiletest to reduce the amount of changes in that follow-up work. I also think that this is useful even without that follow-up work.
[Test] issue-122805.rs should limit to little endian target
In issue-122805.rs, codegen on big endian target is different from little endian target.
```llvm
%0 = load <8 x i16>, ptr %value, align 2
store <8 x i16> %0, ptr %_0, align 1
ret void
```
This is expected since the conversion is unnecessary on BE target for this case.
compiletest: properly handle revisioned run-rustfix tests
Before this PR, if you have a revisioned `//@ run-rustfix` test like `//`@[foo]` run-rustfix`, you would run into an error saying crate name cannot contain `.` characters because the fixed test file trying to be compiled is named `<test-name>.<revision>.fixed`, from which `rustc` infers the crate name to be `<test-name>.<revision>` which is not a valid crate name.
This PR fixes the problem by constructing a synthetic crate name from `<test-name>.<revision>`, by
1. replacing all `-` with `_`, and
2. replacing all `.` with `__`
and pass that constructed crate name with `--crate-name` to rustc to compile the fixed file.
Fixes https://github.com/rust-lang/rust/issues/123596.
Rollup of 2 pull requests
Successful merges:
- #123584 (Emit an error when `rustc_doc_primitive` has an unknown value)
- #123589 (sys_common::thread_local_key: make a note that this is not used on Windows)
r? `@ghost`
`@rustbot` modify labels: rollup
sys_common::thread_local_key: make a note that this is not used on Windows
This just confused me for a while. I don't have the time to clean it up but I can at least leave a note for the next wary traveler.
Use unchecked_sub in str indexing
https://github.com/rust-lang/rust/pull/108763 applied this logic to indexing for slices, but of course `str` has its own separate impl.
Found this by skimming over the codegen for https://github.com/oxidecomputer/hubris/; their dist builds enable overflow checks so the lack of `unchecked_sub` was producing an impossible-to-hit overflow check and also inhibiting some inlining.
r? scottmcm
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
Add `f16` and `f128` to rustdoc's `PrimitiveType`
Fix a few places where these primitives were missing from librustdoc. This should fix the CI failures from doc links in https://github.com/rust-lang/rust/pull/122470.
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
```
