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
Stop using specialization in rustc_index and rustc_borrowck
For rustc_borrowck the version with specialization isn't much more readable anyway IMO. For rustc_index it probably doesn't affect perf in any noticeable way anyway.
Make jump threading state sparse
Continuation of https://github.com/rust-lang/rust/pull/127024
Both dataflow const-prop and jump threading involve cloning the state vector a lot. This PR replaces the data structure by a sparse vector, considering:
- that jump threading state is typically very sparse (at most 1 or 2 set entries);
- that dataflow const-prop is disabled by default;
- that place/value map is very eager, and prone to creating an overly large state.
The first commit is shared with the previous PR to avoid needless conflicts.
r? `@oli-obk`
Implement the `_mm256_zeroupper` and `_mm256_zeroall` intrinsics
These two intrinsics were missing from the original implementation of the AVX intrinsics.
Fortunately their implementation is trivial.
fix: Don't emit semantic diagnostics in files with a lot of syntax errors
These will only add to the noise when something very unexpected breaks or where parser recovery fails to kick in.
fix: Skip match exhaustiveness checking if pattern type contains errors
Should fix https://github.com/rust-lang/rust-analyzer/issues/17509, checking when errors are involved is generally a bad idea as the algorithm doesn't really expect error types in the first place I believe
Check alias args for WF even if they have escaping bound vars
#### What
This PR stops skipping arguments of aliases if they have escaping bound vars, instead recursing into them and only discarding the resulting obligations referencing bounds vars.
#### An example:
From the test:
```
trait Trait {
type Gat<U: ?Sized>;
}
fn test<T>(f: for<'a> fn(<&'a T as Trait>::Gat<&'a [str]>)) where for<'a> &'a T: Trait {}
//~^ ERROR the size for values of type `[()]` cannot be known at compilation time
fn main() {}
```
We now prove that `str: Sized` in order for `&'a [str]` to be well-formed. We were previously unconditionally skipping over `&'a [str]` as it referenced a buond variable. We now recurse into it and instead only discard the `[str]: 'a` obligation because of the escaping bound vars.
#### Why?
This is a change that improves consistency about proving well-formedness earlier in the pipeline, which is necessary for future work on where-bounds in binders and correctly handling higher-ranked implied bounds. I don't expect this to fix any unsoundness.
#### What doesn't it fix?
Specifically, this doesn't check projection predicates' components are well-formed, because there are too many regressions: https://github.com/rust-lang/rust/pull/123737#issuecomment-2052198478
Bootstrap: Try renaming the file if removing fails
Second attempt at working around https://github.com/rust-lang/rust/issues/127126
If we can't remove the file, then try renaming it. This will leave the destination path free to use.
try-job: x86_64-msvc-ext
Use the symbol_name query instead of trying to infer from the link_name attribute
This prevents the calculated name from going out of sync with exported_symbols. It also avoids having to special case the panic_impl lang item.
It also makes it easier to fix miri with https://github.com/rust-lang/rust/pull/127173.
do not normalize `use foo::{self}` to `use foo`
It changes behaviour and can cause collisions. E.g. for the following snippet
```rs
mod foo {
pub mod bar {}
pub const bar: i32 = 8;
}
// transforming the below to `use foo::bar;` causes the error:
//
// the name `bar` is defined multiple times
use foo::bar::{self};
const bar: u32 = 99;
fn main() {
let local_bar = bar;
}
```
we still normalize
```rs
use foo::bar;
use foo::bar::{self};
```
to `use foo::bar;` because this cannot cause collisions.
See: https://github.com/rust-lang/rust-analyzer/pull/17140#issuecomment-2079189725
