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
Older versions of git (≤ 1.8.5) do not support the `-C dir` global
option. Use the `cwd` optional argument when using Python's
`subprocess` functionality instead.
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.
Do not run ui test if options specific to LLVM are used when another codegen backend is used
Based on errors in https://github.com/rust-lang/rust/pull/146414, some tests with LLVM-specific options are run when another codegen is actually the one used.
This PR ignores these tests in such cases now to prevent this situation.
r? `@kobzol`
bootstrap: emit hint if a config key is used in the wrong section
based on discussion on rust-lang/rust#146591
now, if the user puts `build.download-rustc` in `bootstrap.toml`, they'll get a diagnostic:
``hint: try moving `download-rustc` to the `rust` section``
and if they nest things too much (`rust.rust.download-rustc`):
``hint: section name `rust` used as a key within a section``
if they specify a top-level key within a section (`rust.profile`):
``hint: try using `profile` as a top level key``
r? `@Kobzol`
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`
When writing something like the expression `|_: ...| {}`, we now detect the `...` during parsing explicitly instead of relying on the detection in `parse_ty_common` so that we don't talk about "nested `...` are not supported".
```
error: unexpected `...`
--> $DIR/no-closure.rs:6:35
|
LL | const F: extern "C" fn(...) = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
This recognizes the following expression as being equivalent to the
question mark:
```rust
match x {
Ok(v) => v,
Err(e) => return Err(e.into()), // or `Into::into(x)` or `<T as Into<U>>::into(x)`
}
```
Fixesrust-lang/rust-clippy#15679
changelog: [`question_mark`]: recognizes a match with an early return
with a call to `.into()` as possibly equivalent to a question mark
bootstrap: lower verbosity of cargo to one less than bootstrap's
the main thing this does is eliminate the "Fresh ..." output when `--verbose` is only passed once.
r? `@Kobzol`
improve internal bootstrap docs
Mainly focused on making it easier to figure out how tools get built without having to read the `bootstrap_tool!` macro, but also added some subdirs of `build/` to the readme.
compiletest: Make `./x test --test-args ...` work again
It accidentally broke with https://github.com/rust-lang/rust/pull/146501. The intention of that PR was to keep existing behavior if `--exact` is not used, but it had a bug. This PR fixes that bug.
compiletest: Enable new-output-capture by default
The new output-capture implementation was added in rust-lang/rust#146119, but was disabled by default and required opt-in.
Since then, I haven't encountered any problems in my own testing/usage, and I haven't heard any problem reports from other contributors who might have opted in.
It's unlikely that more opt-in testing will help, so the next step is to enable new-output-capture by default and see if anyone complains. (Hopefully nobody!)
If needed, the new default can be overridden (for now) by setting environment variable `COMPILETEST_NEW_OUTPUT_CAPTURE=off`. Please file an issue (or let me know) if anyone finds a reason to do this.
r? jieyouxu
llvm-wrapper: other cleanup
Cleanup few things around llvm-wrapper:
First commit removes unused macro, added back in https://github.com/rust-lang/rust/pull/31709 it was used in `LLVMRustHasFeature`; second removes unused function, third one removes `jsbackend` llvm component - this is looks like remnants of some removed backend?
interpret: fix overlapping aggregate initialization
This fixes the problem pointed out by ````@saethlin```` in https://github.com/rust-lang/rust/issues/146383#issuecomment-3273224645.
Also clarify when exactly current de-facto MIR semantics allow overlap of the LHS and RHS in an assignment.
