Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146442 (Display ?Sized, const, and lifetime parameters in trait item suggestions across a crate boundary)
- rust-lang/rust#146474 (Improve `core::ascii` coverage)
- rust-lang/rust#146605 (Bump rustfix 0.8.1 -> 0.8.7)
- rust-lang/rust#146611 (bootstrap: emit hint if a config key is used in the wrong section)
- rust-lang/rust#146618 (Do not run ui test if options specific to LLVM are used when another codegen backend is used)
r? `@ghost`
`@rustbot` modify labels: rollup
Keep space if arg does not follow punctuation when lint unused parens
Fixesrust-lang/rust#138234
If the arg follows punctuation, still pass `left_pos` with `None` and no space will be added, else then pass `left_pos` with `Some(arg.span.lo())`, so that we can add the space as expected.
And `emit_unused_delims` can make sure no more space will be added if the expr follows space.
---
Edited:
Directly use the `value_span` to check whether the expr removed parens will follow identifier or be followed by identifier.
Bump rustfix 0.8.1 -> 0.8.7
This commit can be replicated by running `cargo update -p rustfix --precise 0.8.7 && x test ui --bless`.
---
The reasons this affects UI tests is as follows:
- The UI test suite runs rustc with `-Z deduplicate-diagnostics=no --error-format=json`, which means that rustc emits multiple errors containing identical suggestions. That caused the weird-looking code that had multiple `X: Copy` suggestions.
- Those suggestions are interpreted not by rustc itself, but by the `rustfix` library, maintained by cargo but published as a separate crates.io library and used by compiletest.
- Sometime between rustfix 0.8.1 and 0.8.7 (probably in rust-lang/cargo#14747, but it's hard to tell because rustfix's versioning doesn't match cargo's), rustfix got smarter and stopped applying duplicate suggestions.
Update rustfix to match cargo's behavior. Ideally, we would always share a version of rustfix between cargo and rustc (perhaps with a path dependency?), to make sure we are testing the behavior we ship. But for now, just manually update it to match.
Note that the latest version of rustfix published to crates.io is 0.9.1, not 0.8.7. But 0.9.1 is not the version used in cargo, which is 0.9.3. Rather than trying to match versions exactly, I just updated rustfix to the latest in the 0.8 branch.
Display ?Sized, const, and lifetime parameters in trait item suggestions across a crate boundary
context: rust-lang/rust#145929
This fixes the MetaSized issue and adds const generics and early bound lifetimes. Late bound lifetimes are harder because they aren't returned by `generics_of`. I'm going to look into it, but there's no guarantee I'll be successful.
Fixes https://github.com/rust-lang/rust/issues/146404.
r? `@BoxyUwu`
Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_`
Now that we have ``#[unstable_feature_bound]``, we can remove ``UnsizedConstParamTy`` that was meant to be an unstable impl of stable type and ``ConstParamTy_`` trait.
r? `@BoxyUwU`
rustc_codegen_llvm: Adjust RISC-V inline assembly's clobber list
Despite that the `fflags` register (representing floating point exception flags) is stated as a flag register [in the reference](https://doc.rust-lang.org/reference/inline-assembly.html#r-asm.rules.preserved-registers), it's not
in the default clobber list of the RISC-V inline assembly and it would be better to fix it.
tests/codegen-llvm: Make rust-abi-arch-specific-adjustment portable
This test currently only runs on RISC-V and loongarch hosts, but assumes that the host target is the -gnu target. By using minicore, we can run this test on all host targets, regardless of architecture, as long as the LLVM components are built.
This also fixes this test on musl hosts of these architectures (though I've only tested on loongarch64-unknown-linux-musl).
This commit can be replicated by running
`cargo update -p rustfix --precise 0.8.7 && x test ui --bless`.
---
The reasons this affects UI tests is as follows:
- The UI test suite runs rustc with
`-Z deduplicate-diagnostics=no --error-format=json`,
which means that rustc emits multiple errors containing identical
suggestions. That caused the weird-looking code that had multiple `X: Copy` suggestions.
- Those suggestions are interpreted not by rustc itself, but by the
`rustfix` library, maintained by cargo but published as a separate
crates.io library and used by compiletest.
- Sometime between rustfix 0.8.1 and 0.8.7 (probably in cargo 14747, but
it's hard to tell because rustfix's versioning doesn't match cargo's),
rustfix got smarter and stopped applying duplicate suggestions.
Update rustfix to match cargo's behavior. Ideally, we would always share
a version of rustfix between cargo and rustc (perhaps with a path
dependency?), to make sure we are testing the behavior we ship. But for
now, just manually update it to match.
Note that the latest version of rustfix published to crates.io is 0.9.1,
not 0.8.7. But 0.9.1 is not the version used in cargo, which is 0.9.3.
Rather than trying to match versions exactly, I just updated rustfix to
the latest in the 0.8 branch.
Despite that the `fflags` register (representing floating point
exception flags) is stated as a flag register in the reference, it's not
in the default clobber list of the RISC-V inline assembly and it would
be better to fix it.
document `core::ffi::VaArgSafe`
tracking issue: https://github.com/rust-lang/rust/issues/44930
A modification of https://github.com/rust-lang/rust/pull/146454, keeping just the documentation changes, but not unsealing the trait.
Although conceptually we'd want to unseal the trait, there are many edge cases to supporting arbitrary types. We'd need to exhaustively test that all targets/calling conventions support all types that rust might generate (or generate proper error messages for unsupported cases). At present, many of the `va_arg` implementations assume that the argument is a scalar, and has an alignment of at most 8. That is totally sufficient for an MVP (accepting all of the "standard" C types), but clearly does not cover all rust types.
This PR also adds some various other tests for edge cases of c-variadic:
- the `#[inline]` attribute in its various forms. At present, LLVM is unable to inline c-variadic functions, but the attribute should still be accepted. `#[rustc_force_inline]` already rejects c-variadic functions.
- naked functions should accept and work with a C variable argument list. In the future we'd like to allow more ABIs with naked functions (basically, any ABI for which we accept defining foreign c-variadic functions), but for now only `"C"` and `"C-unwind` are supported
- guaranteed tail calls: c-variadic functions cannot be tail-called. That was already rejected, but there was not test for it.
r? `@workingjubilee`
Make `AssocItem` aware of its impl kind
The general goal is to have fewer query dependencies by making `AssocItem` aware of its parent impl kind (inherent vs. trait) without having to query the parent def_kind.
See individual commits.
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#3 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Add --print target-spec-json-schema
This schema is helpful for people writing custom target spec JSON. It can provide autocomplete in the editor, and also serves as documentation when there are documentation comments on the structs, as `schemars` will put them in the schema.
I was motivated to do this because I saw someone write their own version of this schema by hand, so demand for this clearly exists. It's not a lot of effort to implement, so I thought it would make sense.
MCP: https://github.com/rust-lang/compiler-team/issues/905
I think it would also be useful to put this in the sysroot in `etc` so people can link it directly in their editors.
I would have loved to add a test that validates the JSON schema against the spec JSON of every builtin target, but I don't want to do it as the JSON schema validation crates have incredible amounts of dependencies because JSON schema supports a ton of random features. I don't want to add that, even as a dev dependency.
Convert `no_std` and `no_core` to the new attribute infrastructure
r? ```@oli-obk```
Also added a test for these, since we didn't have any and I was kind of surprised new diagnostics didn't break anything hehe
This schema is helpful for people writing custom target spec JSON. It
can provide autocomplete in the editor, and also serves as documentation
when there are documentation comments on the structs, as `schemars` will
put them in the schema.
test: remove an outdated normalization for rustc versions
These "you are using $RUSTC_VERSION" help messages were removed in
rust-lang/rust#142943, but rust-lang/rust#142681 started before that and
merged later, so its normalization is vestigial.
Improve suggestion in case a bare URL is surrounded by brackets
Fixes https://github.com/rust-lang/rust/issues/146162.
With this change, output looks like this:
```
|
1 | //! [https://github.com]
| ^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://github.com>`
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
```
cc ```@fmease```
r? ```@lolbinarycat```
support integer literals in `${concat()}`
Tracking issue: rust-lang/rust#124225
Adds support for using integer literals as arguments to `${concat()}` macro expressions.
Integer formatting such as `1_000` is preserved by this.
match clang's `va_arg` assembly on arm targets
tracking issue: https://github.com/rust-lang/rust/issues/44930
For this example
```rust
#![feature(c_variadic)]
#[unsafe(no_mangle)]
unsafe extern "C" fn variadic(a: f64, mut args: ...) -> f64 {
let b = args.arg::<f64>();
let c = args.arg::<f64>();
a + b + c
}
```
We currently generate (via llvm):
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d0, r0, r1
add r0, sp, #4
vldr d1, [sp, #4]
add r0, r0, #15
bic r0, r0, #7
vadd.f64 d0, d0, d1
add r1, r0, #8
str r1, [sp]
vldr d1, [r0]
vadd.f64 d0, d0, d1
vmov r0, r1, d0
add sp, sp, #12
bx lr
```
LLVM is not doing a good job. In fact, it's well-known that LLVM's implementation of `va_arg` is kind of bad, and we implement it ourselves (based on clang) for many targets already. For arm, our own `emit_ptr_va_arg` saves 3 instructions.
Next, it turns out it's important for LLVM to explicitly start and end the lifetime of the `va_list`. In https://github.com/rust-lang/rust/pull/146059 I already end the lifetime, but when looking at this again, I noticed that it is important to also start it, see https://godbolt.org/z/EGqvKTTsK: failing to explicitly start the lifetime uses an extra register.
So, the combination of `emit_ptr_va_arg` with starting/ending the lifetime makes rustc emit exactly the instructions that clang generates::
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d16, r0, r1
vldr d17, [sp, #4]
vadd.f64 d16, d16, d17
vldr d17, [sp, #12]
vadd.f64 d16, d16, d17
vmov r0, r1, d16
add sp, sp, #12
bx lr
```
The arguments to `emit_ptr_va_arg` are based on [the clang implementation](03dc2a41f3/clang/lib/CodeGen/Targets/ARM.cpp (L798-L844)).
r? ``@workingjubilee`` (I can re-roll if your queue is too full, but you do seem like the right person here)
try-job: armhf-gnu
