Bootstrap command refactoring: quality-of-life improvements (step 4)
Continuation of https://github.com/rust-lang/rust/pull/127120.
This PR simply introduce two new functions (`BootstrapCommand:run` and `command`) that make it a bit easier to use commands in bootstrap. It also adds several `#[must_use]` annotations. This shouldn't (hopefully) have any effect on behavior.
Especially the first commit IMO makes any code that runs commands more readable, and allows using the API in a fluent way, without needing to jump back and forth between the command and the `Build(er)`.
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
Add `new_range_api` for RFC 3550
Initial implementation for #125687
This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC. Having `From` is highly convenient and the debug assert should find almost all misuses.
This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.
Currently the iterators are just wrappers around the old range types.
Tracking issues:
- https://github.com/rust-lang/rust/issues/123741
- https://github.com/rust-lang/rust/issues/125687
Rollup of 8 pull requests
Successful merges:
- #123600 (impl PathBuf::add_extension and Path::with_added_extension)
- #127107 (Improve dead code analysis)
- #127221 (Improve well known value check-cfg diagnostic for the standard library)
- #127333 (Split `SolverDelegate` back out from `InferCtxtLike`)
- #127363 (Improve readability of some fmt code examples)
- #127366 (Use `ControlFlow` results for visitors that are only looking for a single value)
- #127368 (Added dots at the sentence ends of rustc AST doc)
- #127393 (Remove clubby789 from review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve dead code analysis
Fixes#120770
1. check impl items later if self ty is private although the trait method is public, cause we must use the ty firstly if it's private
2. mark the adt live if it appears in pattern, like generic argument, this implies the use of the adt
3. based on the above, we can handle the case that private adts impl Default, so that we don't need adding rustc_trivial_field_reads on Default, and the logic in should_ignore_item
r? ``@pnkfelix``
This includes a `From<legacy::RangeInclusive> for RangeInclusive` impl for convenience, instead of the `TryFrom` impl from the RFC.
Having `From` is highly convenient and the assertion is unlikely to be a problem in practice.
This includes re-exports of all existing `Range` types under `core::range`, plus the range-related traits (`RangeBounds`, `Step`, `OneSidedRange`) and the `Bound` enum.
Currently the iterators are just wrappers around the old range types,
and most other trait impls delegate to the old rage types as well.
Also includes an `.iter()` shorthand for `.clone().into_iter()`
Make CI more agnostic of the owning GitHub organization
This should make it possible to switch running `auto` and `try` builds from `rust-lang-ci` to `rust-lang`.
r? `@jdno`
Update windows-bindgen to 0.58.0
This also switches from the bespoke `std` generated bindings to the normal `sys` ones everyone else uses.
This has almost no difference except that the `sys` bindings use the `windows_targets::links!` macro for FFI imports, which we implement manually. This does cause the diff to look much larger than it really is but the bulk of the changes are mostly contained to the generated code.
Migrate `include_bytes_deps`, `optimization-remarks-dir-pgo`, `optimization-remarks-dir`, `issue-40535` and `rmeta-preferred` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Needs BSD tryjob.
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: armhf-gnu
try-job: test-various
Match ergonomics 2024: Implement TC's match ergonomics proposal
Under gate `ref_pat_eat_one_layer_2024_structural`. Enabling `ref_pat_eat_one_layer_2024` at the same time allows the union of what the individual gates allow. `@traviscross`
r? `@Nadrieril`
cc https://github.com/rust-lang/rust/issues/123076
`@rustbot` label A-edition-2024 A-patterns
Miri function identity hack: account for possible inlining
Having a non-lifetime generic is not the only reason a function can be duplicated. Another possibility is that the function may be eligible for cross-crate inlining. So also take into account the inlining attribute in this Miri hack for function pointer identity.
That said, `cross_crate_inlinable` will still sometimes return true even for `inline(never)` functions:
- when they are `DefKind::Ctor(..) | DefKind::Closure` -- I assume those cannot be `InlineAttr::Never` anyway?
- when `cross_crate_inline_threshold == InliningThreshold::Always`
so maybe this is still not quite the right criterion to use for function pointer identity.
Tweak some structured suggestions to be more verbose and accurate
Addressing some issues I found while working on #127282.
```
error: this URL is not a hyperlink
--> $DIR/auxiliary/include-str-bare-urls.md:1:11
|
LL | HEADS UP! https://example.com MUST SHOW UP IN THE STDERR FILE!
| ^^^^^^^^^^^^^^^^^^^
|
= note: bare URLs are not automatically turned into clickable links
note: the lint level is defined here
--> $DIR/include-str-bare-urls.rs:14:9
|
LL | #![deny(rustdoc::bare_urls)]
| ^^^^^^^^^^^^^^^^^^
help: use an automatic link instead
|
LL | HEADS UP! <https://example.com> MUST SHOW UP IN THE STDERR FILE!
| + +
```
```
error[E0384]: cannot assign twice to immutable variable `v`
--> $DIR/assign-imm-local-twice.rs:7:5
|
LL | v = 1;
| ----- first assignment to `v`
LL | println!("v={}", v);
LL | v = 2;
| ^^^^^ cannot assign twice to immutable variable
|
help: consider making this binding mutable
|
LL | let mut v: isize;
| +++
```
```
error[E0393]: the type parameter `Rhs` must be explicitly specified
--> $DIR/issue-22560.rs:9:23
|
LL | trait Sub<Rhs=Self> {
| ------------------- type parameter `Rhs` must be specified for this
...
LL | type Test = dyn Add + Sub;
| ^^^
|
= note: because of the default `Self` reference, type parameters must be specified on object types
help: set the type parameter to the desired type
|
LL | type Test = dyn Add + Sub<Rhs>;
| +++++
```
```
error[E0596]: cannot borrow `v` as mutable, as it is not declared as mutable
--> $DIR/issue-33819.rs:4:34
|
LL | Some(ref v) => { let a = &mut v; },
| ^^^^^^ cannot borrow as mutable
|
help: try removing `&mut` here
|
LL - Some(ref v) => { let a = &mut v; },
LL + Some(ref v) => { let a = v; },
|
```
```
help: remove the invocation before committing it to a version control system
|
LL - dbg!();
|
```
```
error[E0308]: mismatched types
--> $DIR/issue-39974.rs:1:21
|
LL | const LENGTH: f64 = 2;
| ^ expected `f64`, found integer
|
help: use a float literal
|
LL | const LENGTH: f64 = 2.0;
| ++
```
```
error[E0529]: expected an array or slice, found `Vec<i32>`
--> $DIR/match-ergonomics.rs:8:9
|
LL | [&v] => {},
| ^^^^ pattern cannot match with input type `Vec<i32>`
|
help: consider slicing here
|
LL | match x[..] {
| ++++
```
```
error[E0609]: no field `0` on type `[u32; 1]`
--> $DIR/parenthesized-deref-suggestion.rs:10:21
|
LL | (x as [u32; 1]).0;
| ^ unknown field
|
help: instead of using tuple indexing, use array indexing
|
LL | (x as [u32; 1])[0];
| ~ +
```
This makes it easier to use commands in a "Fluent-API" style, and also removes the need for the `AsMut` trait hack that
was used before to allow passing both `BootstrapCommand` and `&mut BootstrapCommand` to `Builder::run`.
The `Builder::run` method was still kept and can be used explicitly, if needed for some reason.
Bootstrap command refactoring: consolidate output modes (step 3)
This PR is a continuation to https://github.com/rust-lang/rust/pull/126731. It consolidates the output modes of bootstrap (`Print` vs `CaptureAll` vs `CaptureStdout`) and simplifies the logic around error printing (now a command error is always printed if the failure is not ignored). It also ports even more usages of `Command` to `BootstrapCommand`, most notably the git helpers and many usages of the `output` function.
The last commit was added because the third commit made two variants of the `Tool` enum unused (no idea why, but it seems to have been a false positive that they were used before).
It can be reviewed now, but I would wait with merging until at least a few days after https://github.com/rust-lang/rust/pull/126731, just to catch any potential issues from that PR before we move further.
As a next step, I want to clean up the API of the command a little bit to make usage easier (currently it's a bit verbose), and then continue with the rest of the tasks from the tracking issue.
As always, best reviewed commit by commit.
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
try-job: aarch64-apple
TB: Refine protector end semantics
Tree Borrows has protector end tag semantics, namely that protectors ending cause a [special implicit read](https://perso.crans.org/vanille/treebor/diff.0.html) on all locations protected by that protector that have actually been accessed. See also #3067.
While this is enough for ensuring protectors allow adding/reordering reads, it does not prove that one can reorder writes. For this, we need to make this stronger, by making this implicit read be a write in cases when there was a write to the location protected by that protector, i.e. if the permission is `Active`.
There is a test that shows why this behavior is necessary, see `tests/fail/tree_borrows/protector-write-lazy.rs`.
