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`
fix: Fix runnables being incorrectly constructed
I've misunderstood parts of the code here which caused runnables to arbitrarily break :) (I have yet to understand the conditions that made them break though, there is some odd caching involved I feel like ...)
Fixes https://github.com/rust-lang/rust-analyzer/issues/17402
Elaboration tweaks
Removes `Filter::OnlySelfThatDefines` and reimplements `transitive_bounds_that_define_assoc_item` as a separate function, since I don't want to have to uplift that mode since it's both an implementation detail (only exists to avoid cycles in astconv) and requires exposing `Ident` as an associated type on `Interner`.
r? lcnr
internal: Clean up runnable lsp extension
This feels like a natural addition to me, and also allows us to drop the expect-test hardcoding from the extension. Additionally, `cargoExtraArgs` is pointless, all the client will do is merge it with `cargoArgs` so the server can do that instead of delegating that to the client.
implement `libc::sched_setaffinity` on linux
fixes https://github.com/rust-lang/miri/issues/2749
the implementation, like `libc::sched_getaffinity`, just always returns `EINVAL`, which kind of simulates a device with zero cpus. I believe the idea is that callers of this function always do it to optimize, so they are likely to gracefully recover from this function returning an error.
based on the libc crate, these functions are also available on android and freebsd (but not on macos or windows). So should the implementation of the `sched_*` functions just be copied to the android and freebsd shims?
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
Remove clubby789 from review rotation
These days I'm unfortunately too busy to be able to take up reviews, and it looks like some PRs have been blocked on this 😓
Added dots at the sentence ends of rustc AST doc
Just a tiny improvement for the AST documentation by bringing consistency to sentence ends. I intentionally didn't terminate every sentence, there are still some members not having them, but at least there's no mixing style on the type level.
Use `ControlFlow` results for visitors that are only looking for a single value
These visitors all had a `Option<Value>` or `bool` field, that, once set, was never unset or modified again. They have been refactored by removing the field and returning `ControlFlow` directly from the visitor
Improve readability of some fmt code examples
Some indent was weird. Some examples were too long (overall better to keep it to maximum 80 columns, but only changed the most outstanding ones).
r? ```@Amanieu```
Split `SolverDelegate` back out from `InferCtxtLike`
This is because in order to uplift things like the `Generalizer` and other `TypeRelation`s, we want to be able to interface with `InferCtxtLike` (and `InferCtxt` as its implementation), rather that `SolverDelegate`, which only really exists as a hack to be able to define some downstream methods in `rustc_type_ir`.
r? lcnr
Improve well known value check-cfg diagnostic for the standard library
This PR adjust the current logic for hidding the rustc/Cargo suggestion to add a value to a well-known name to exclude the standard library and rustc crates.
This is done in order to improve the contributor experience, in particular when adding a new target, which often requires adding some cfgs like `target_os` which may not be available yet in stage0.
<details>
The diagnostic code would look like this.
```text
error: unexpected `cfg` condition value: `blable`
--> library/core/src/lib.rs:369:7
|
369 | #[cfg(target_os = "blable")]
| ^^^^^^^^^^^^^^^^^^^^
|
= note: expected values for `target_os` are: `aix`, `android`, `cuda`, `dragonfly`, `emscripten`, `espidf`, `freebsd`, `fuchsia`, `haiku`, `hermit`, `horizon`, `hurd`, `illumos`, `ios`, `l4re`, `linux`, `macos`, `netbsd`, `none`, `nto`, `openbsd`, `psp`, `redox`, `solaris`, `solid_asp3`, `teeos`, `tvos`, `uefi`, `unknown`, `visionos`, `vita`, `vxworks`, `wasi`, `watchos`, and `windows` and 2 more
= help: consider using a Cargo feature instead
= help: or consider adding in `Cargo.toml` the `check-cfg` lint config for the lint:
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(target_os, values("blable"))'] }
= help: or consider adding `println!("cargo::rustc-check-cfg=cfg(target_os, values(\"blable\"))");` to the top of the `build.rs`
= note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
= note: `-D unexpected-cfgs` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unexpected_cfgs)]`
```
</details>
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``
Disallow nested impl traits
Fixes#17498
The above issue is due to formatting self referencing, recursive bound like `Implemented(^0.0: TraitId(0)<[?0 := ^0.0]>)` on the codes like;
```rust
trait Foo<T> {}
trait Bar {}
fn test(foo: impl Foo<impl Bar>) { ... }
```
When lowering predicate `impl Foo<impl Bar>` in `trait_environment_query`, the outer `impl Foo<...>` is treated as predicates, so the first `TypeRef` that passes the following code is `impl Bar`;
cae997e338/crates/hir-ty/src/lower.rs (L376-L400)
and thus the `idx` is `0` in the above context.
But the following code sets `self_ty` as the `BoundVar` with `idx = 0` because the target param id for predicate `impl Foo<...>` is `0` since `impl Foo` is the first generic-like parameter of `fn test`;
cae997e338/crates/hir-ty/src/lower.rs (L998-L1025)
For the codes like;
```rust
trait Foo {
type Assoc;
}
trait Bar {}
fn test(foo: impl Foo<Assoc = impl Bar>) { ... }
```
similar recursive bound doesn't happen because the following codes ***"count the number of `impl Trait` things that appear before the target of our `bound`."***
cae997e338/crates/hir-ty/src/lower.rs (L1168-L1199)
Instead of doing similar thing like nested `impl Foo<impl Bar>` thing, this PR lowers such nested impl traits into error types in the similar manner as the rustc does in the following lines (and of course, allows lowering and inferencing nested impl traits for the cases that rustc permits);
- e2cf31a614/compiler/rustc_ast_passes/src/ast_validation.rs (L802-L813)
- 7b21c18fe4/compiler/rustc_ast_passes/src/ast_validation.rs (L1299-L1314)
(Though rustc emits [E0666😈](https://doc.rust-lang.org/error_codes/E0666.html), I skipped diagnostics since gathering diagnostics in `hir-def` has no conventions so far 😅)
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
