Rollup of 7 pull requests
Successful merges:
- #133358 (Don't type error if we fail to coerce `Pin<T>` because it doesnt contain a ref)
- #133422 (Fix clobber_abi in RV32E and RV64E inline assembly)
- #133452 (Support predicate registers (clobber-only) in Hexagon inline assembly)
- #133463 (Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18)
- #133487 (fix confusing diagnostic for reserved `##`)
- #133557 (Small doc fixes in `rustc_codegen_ssa`)
- #133560 (Trim extra space in 'repeated `mut`' diagnostic)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 12 pull requests
Successful merges:
- #129409 (Expand std::os::unix::fs::chown() doc with a warning)
- #133320 (Add release notes for Rust 1.83.0)
- #133368 (Delay a bug when encountering an impl with unconstrained generics in `codegen_select`)
- #133428 (Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`)
- #133512 (Add `as_array` and `as_mut_array` conversion methods to slices.)
- #133519 (Check `xform_ret_ty` for WF in the new solver to improve method winnowing)
- #133520 (Structurally resolve before applying projection in borrowck)
- #133534 (extend group-forbid-always-trumps-cli test)
- #133537 ([rustdoc] Fix new clippy lints)
- #133543 ([AIX] create shim for lgammaf_r)
- #133547 (rustc_span: Replace a `HashMap<_, ()>` with `HashSet`)
- #133550 (print generated doc paths)
r? `@ghost`
`@rustbot` modify labels: rollup
Some more refactorings towards removing driver queries
Follow up to https://github.com/rust-lang/rust/pull/127184
## Custom driver breaking change
The `after_analysis` callback is changed to accept `TyCtxt` instead of `Queries`. The only safe query in `Queries` to call at this point is `global_ctxt()` which allows you to enter the `TyCtxt` either way. To fix your custom driver, replace the `queries: &'tcx Queries<'tcx>` argument with `tcx: TyCtxt<'tcx>` and remove your `queries.global_ctxt().unwrap().enter(|tcx| { ... })` call and only keep the contents of the closure.
## Custom driver deprecation
The `after_crate_root_parsing` callback is now deprecated. Several custom drivers are incorrectly calling `queries.global_ctxt()` from inside of it, which causes some driver code to be skipped. As such I would like to either remove it in the future or if custom drivers still need it, change it to accept an `&rustc_ast::Crate` instead.
miri: implement `TlsFree`
If the variable does not need a destructor, `std` uses racy initialization for creating TLS keys on Windows. With just the right timing, this can lead to `TlsFree` being called. Unfortunately, with #132654 this is hit quite often, so miri should definitely support `TlsFree` ([documentation](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsfree)).
I'm filing this here instead of in the miri repo so that #132654 isn't blocked for so long.
Commit license-metadata.json to git and check it's correct in CI
This PR adds `license-metadata.json` to the root of the git repo, and changes `mingw-check` to check that the file is still up-to-date.
By committing this file, we remove the need for developers to a) have reuse installed or b) run an expensive ~90 second analysis of the files on disk when they want generate the COPYRIGHT.html files which depend on this license metadata.
The file will need updating whenever `REUSE.toml` changes, or when git submodules are added, or when git submodules change their license information (as detected by REUSE).
You can now run:
* `./x run collect-license-metadata` to update the `./license-metadata.json` file
* `./x test collect-license-metadata` to test the `./license-metadata.json` file for correctness
The comparison is done with two `serde_json::Value` objects, so the map objects they contain should ignore differences in ordering.
use `--exact` on `--skip` to avoid unintended substring matches
Without the `--exact` flag, using `--skip tests/rustdoc` can unintentionally skip other tests that match as substrings such as `rustdoc-gui`, `rustdoc-js`, etc.
For debugging, run: `./x.py --stage 2 test rustdoc-ui --skip tests/rustdoc` and `./x.py --stage 2 test rustdoc-ui --skip tests/rustdoc -- --exact`
Resolves https://github.com/rust-lang/rust/issues/117721
try-job: x86_64-apple-1
Fix `Result` and `Option` not getting a jump to def link generated
It was just because we didn't store the "span" in the `PreludeTy` variant.
r? ``@notriddle``
Remove -Zfuel.
I'm not sure this feature is used. I only found 2 references in a google search, both referring to its introduction.
Meanwhile, it's a global mutable state, untracked by incremental compilation, so incompatible with it.
Inline ExprPrecedence::order into Expr::precedence
The representation of expression precedence in rustc_ast has been an obstacle to further improvements in the pretty-printer (continuing from #119105 and #119427).
Previously the operation of *"does this expression have lower precedence than that one"* (relevant for parenthesis insertion in macro-generated syntax trees) consisted of 3 steps:
1. Convert `Expr` to `ExprPrecedence` using `.precedence()`
2. Convert `ExprPrecedence` to `i8` using `.order()`
3. Compare using `<`
As far as I can guess, the reason for the separation between `precedence()` and `order()` was so that both `rustc_ast::Expr` and `rustc_hir::Expr` could convert as straightforwardly as possible to the same `ExprPrecedence` enum, and then the more finicky logic performed by `order` could be present just once.
The mapping between `Expr` and `ExprPrecedence` was intended to be as straightforward as possible:
```rust
match self.kind {
ExprKind::Closure(..) => ExprPrecedence::Closure,
...
}
```
although there were exceptions of both many-to-one, and one-to-many:
```rust
ExprKind::Underscore => ExprPrecedence::Path,
ExprKind::Path(..) => ExprPrecedence::Path,
...
ExprKind::Match(_, _, MatchKind::Prefix) => ExprPrecedence::Match,
ExprKind::Match(_, _, MatchKind::Postfix) => ExprPrecedence::PostfixMatch,
```
Where the nature of `ExprPrecedence` becomes problematic is when a single expression kind might be associated with multiple different precedence levels depending on context (outside the expression) and contents (inside the expression). For example consider what is the precedence of an ExprKind::Closure `$closure`. Well, on the left-hand side of a binary operator it would need parentheses in order to avoid the trailing binary operator being absorbed into the closure body: `($closure) + Rhs`, so the precedence is something lower than that of `+`. But on the right-hand side of a binary operator, a closure is just a straightforward prefix expression like a unary op, which is a relatively high precedence level, higher than binops but lower than method calls: `Lhs + $closure` is fine without parens but `($closure).method()` needs them. But as a third case, if the closure contains an explicit return type, then the precedence is an even higher level than that, never needing parenthesization even in a binop left-hand side or method call: `|| -> bool { false } + Rhs` or `|| -> bool { false }.method()`.
You can see that trying to capture all of this resolution about expressions into `ExprPrecedence` violates the intention of `ExprPrecedence` being a straightforward one-to-one correspondence from each AST and HIR `ExprKind` variant. It would be possible to attempt that by doing stuff like `ExprPrecedence::Closure(Side::Leading, ReturnType::No)`, but I don't foresee the original envisioned benefit of the `precedence()`/`order()` distinction being retained in this approach. Instead I want to move toward a model that Syn has been using successfully. In Syn, there is a Precedence enum but it differs from rustc in the following ways:
- There are [relatively few variants](https://github.com/dtolnay/syn/blob/2.0.87/src/precedence.rs#L11-L47) compared to rustc's `ExprPrecedence`. For example there is no distinction at the precedence level between returns and closures, or between loops and method calls.
- We distinguish between [leading](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L293) and [trailing](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L309) precedence, taking into account an expression's context such as what token follows it (for various syntactic bail-outs in Rust's grammar, like ambiguities around break-with-value) and how it relates to operators from the surrounding syntax tree.
- There are no hardcoded mysterious integer quantities like rustc's `PREC_CLOSURE = -40`. All precedence comparisons are performed via PartialOrd on a C-like enum.
This PR is just a first step in these changes. As you can tell from Syn, I definitely think there is value in having a dedicated type to represent precedence, instead of what `order()` is doing with `i8`. But that is a whole separate adventure because rustc_ast doesn't even agree consistently on `i8` being the type for precedence order; `AssocOp::precedence` instead uses `usize` and there are casts in both directions. It is likely that a type called `ExprPrecedence` will re-appear, but it will look substantially different from the one that existed before this PR.
Cleanup: delete `//@ pretty-expanded` directive
This PR removes the `//@ pretty-expanded` directive support in compiletest and removes its usage inside ui tests because it does not actually do anything, and its existence is itself misleading. This PR is split into two commits:
1. The first commit just drops `pretty-expanded` directive support in compiletest.
2. The second commit is created by `sd '//@ pretty-expanded.*\n' '' tests/ui/**/*.rs`[^1], reblessing, and slightly adjusting some leading whitespace in a few tests.
We can tell this is fully removed because compiletest doesn't complain about unknown directive when running the `ui` test suite.
cc #23616
### History
Originally, there was some effort to introduce more test coverage for `-Z unpretty=expanded` (in 2015 this was called `--pretty=expanded`). In [Make it an error to not declare used features #23598][pr-23598], there was a flip from `//@ no-pretty-expanded` (opt-out of `-Z
unpretty=expanded` test) to `//@ pretty-expanded` (opt-in to `-Z unpretty=expanded` test). This was needed because back then the dedicated `tests/pretty` ("pretty") test suite did not existed, and the pretty tests were grouped together under `run-pass` tests (I believe the `ui` test suite didn't exist back then either). Unfortunately, in this process the replacement `//@ pretty-expanded` directives contained a `FIXME #23616` linking to [There are very few tests for `-Z unpretty` expansion #23616][issue-23616]. But this was arguably backwards and somewhat misleading, as noted in [#23616](https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901):
The attribute is off by default and things just work if you don't
test it, people have not been adding the `pretty-expanded`
annotation to new tests even if it would work.
Which basically renders this useless.
### Current status
As of Nov 2024, we have a dedicated `pretty` test suite, and some time over the years the split between `run-pass` into `ui` and `pretty` test suites caused all the `//@ pretty-expanded` in `ui` tests to do absolutely nothing: the compiletest logic for `pretty-expanded` only triggers in the *pretty* test suite, but none of the pretty tests use it. Oops.
Nobody remembers this, nobody uses this, it's misleading in ui tests. Let's get rid of this directive altogether.
[pr-23598]: https://github.com/rust-lang/rust/pull/23598
[issue-23616]: https://github.com/rust-lang/rust/issues/23616
### Follow-ups
- [x] Yeet this directive from rustc-dev-guide docs. https://github.com/rust-lang/rustc-dev-guide/pull/2147
[^1]: https://github.com/chmln/sd
r? compiler
Use ReadCache for archive reading in bootstrap
Address expensive archive reading in bootstrap. This fixes https://github.com/rust-lang/rust/issues/133268
Enable the `std` feature of `object` to use `ReadCache` instead of reading the entire archive file into memory to check for headers. This takes minimal extra time to compile compared to introducing other expensive dependencies to `bootstrap`.
r? jieyouxu
Refactor `where` predicates, and reserve for attributes support
Refactor `WherePredicate` to `WherePredicateKind`, and reserve for attributes support in `where` predicates.
This is a part of #115590 and is split from #132388.
r? petrochenkov
Foreword
========
Let us begin the journey to rediscover what the `//@ pretty-expanded`
directive does, brave traveller --
"My good friend, [..] when I wrote that passage, God and I knew what
it meant. It is possible that God knows it still; but as for me, I
have totally forgotten."
-- Johann Paul Friedrich Richter, 1826
We must retrace the steps of those before us, for history shall guide us
in the present and inform us of the future.
The Past
========
Originally there was some effort to introduce more test coverage for `-Z
unpretty=expanded` (in 2015 this was called `--pretty=expanded`). In
[Make it an error to not declare used features #23598][pr-23598], there
was a flip from `//@ no-pretty-expanded` (opt-out of `-Z
unpretty=expanded` test) to `//@ pretty-expanded` (opt-in to `-Z
unpretty=expanded` test). This was needed because back then the
dedicated `tests/pretty` ("pretty") test suite did not existed, and the
pretty tests were grouped together under `run-pass` tests (I believe
`ui` test suite didn't exist back then either). Unfortunately, in this
process the replacement `//@ pretty-expanded` directives contained a
`FIXME #23616` linking to [There are very few tests for `-Z unpretty`
expansion #23616][issue-23616]. But this was arguably backwards and
somewhat misleading, as noted in
<https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901>:
The attribute is off by default and things just work if you don't
test it, people have not been adding the `pretty-expanded`
annotation to new tests even if it would work.
Which basically renders this useless.
The Present
===========
As of Nov 2024, we have a dedicated `pretty` test suite, and some time
over the years the split between `run-pass` into `ui` and `pretty` test
suites caused all of the `//@ pretty-expanded` in `ui` tests to do
absolutely nothing -- the compiletest logic for `pretty-expanded` only
triggered in the *pretty* test suite, but none of the pretty tests use
it. Oops.
The Future
==========
Nobody remembers this, nobody uses this, it's misleading in ui tests.
Let's get rid of this directive altogether.
[pr-23598]: https://github.com/rust-lang/rust/pull/23598
[issue-23616]: https://github.com/rust-lang/rust/issues/23616
If the variable does not need a destructor, `std` uses racy initialization for creating TLS keys on Windows. With just the right timing, this can lead to `TlsFree` being called. Unfortunately, with #132654 this is hit quite often, so miri should definitely support `TlsFree` ([documentation](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsfree)).
I'm filing this here instead of in the miri repo so that #132654 isn't blocked for so long.
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)
This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.
This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: https://github.com/rust-lang/rust/issues/133416). If the feature is not enabled, only clober is supported as before.
| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |
This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313
In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.
Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in https://github.com/rust-lang/rust/issues/130869.
cc https://github.com/rust-lang/rust/issues/130869 about vector facility support in s390x
cc https://github.com/rust-lang/rust/issues/125398 & https://github.com/rust-lang/rust/issues/116909 about f128 support in asm
`@rustbot` label +O-SystemZ +A-inline-assembly
Rollup of 6 pull requests
Successful merges:
- #132730 (std: allow after-main use of synchronization primitives)
- #133105 (only store valid proc macro item for doc link)
- #133260 (Constify the `Deref`/`DerefMut` traits, too)
- #133297 (Remove legacy bitcode for iOS)
- #133298 (Mention that std::fs::remove_dir_all fails on files)
- #133384 (add a test for target-feature-ABI warnings in closures and when calling extern fn)
r? `@ghost`
`@rustbot` modify labels: rollup
bors