Do not suggest borrowing enclosing calls for nested where-clause obligations
In rust-lang/rust#155088, the compiler was blaming the whole call expr instead of the value that actually failed the trait bound, so for foo(&[String::from("a")]) it was suggesting stuff like &foo(...). I changed the suggestion logic so it only emits borrow help if the expr it found actually matches the failed self type, and used the same check for the “similar impl exists” help too. So now the compiler should give the normal error + required bound note.
Fixrust-lang/rust#155088
Some cleanups around per parent disambiguators
r? @petrochenkov
follow-up to rust-lang/rust#155547
The two remaining uses are
* resolve_bound_vars, where it is a reasonable way to do it instead of having another field in the visitor that needs to get scoped (set & reset) every time we visit an opaque type. May still change that at some point, but it's not really an issue
* `create_def` in the resolver: will get removed together with my other refactorings for `node_id_to_def_id` (making that per-owner)
delegation: rename `Self` generic param to `This` in recursive delegations
This PR supports renaming of `Self` generic parameter to `This` in recursive delegations scenario, this allows propagation of `This` as we rely on `Self` naming to check whether it is implicit Self of a trait. Comment with a bit deeper explanation is in `uplift_delegation_generic_params`. Part of rust-lang/rust#118212.
r? @petrochenkov
Forbid `*-pass` and `*-fail` directives in tests/crashes
Crash tests are always expected to crash during compilation, so there is no sensible meaning for specifying a pass expectation or a run-fail expectation in a crash test.
It could conceivably be useful to use failure expectations to specify whether a crash test requires codegen in order to crash, but currently none of the crash tests try to do that. If that functionality is desired in the future, we can always look into re-adding it after the internals of pass/fail expectations have been cleaned up a bit.
---
After this change, pass/fail directives are only allowed in UI tests, which should make it easier to overhaul and simplify their implementation.
r? jieyouxu
Remove `AttributeLintKind` variants - part 7
Part of https://github.com/rust-lang/rust/issues/153099.
It's the last easy one. Next one will require to get the crate name and to pass `Session` to the remaining lints. Fun times ahead. :)
r? @JonathanBrouwer
Remove myself as a maintainer of `wasm32-wasip1-threads`
Over time the landscape for myself has changed, and I no longer would like to be officially listed as a maintainer of this target in Rust, so I'm going to step down. There are still a number of others listed on this target, however, so I'm sure they can address issues should they come up.
Syntactically reject tuple index shorthands in struct patterns to fix a correctness regression
Split out of PR rust-lang/rust#154492. This fixes a correctness regression introduced in PR rust-lang/rust#81235 from 2021. Crater was run in my other PR and didn't report any real regressions (https://github.com/rust-lang/rust/pull/154492#issuecomment-4187544786); a rerun has been issued for a few spurious builds (https://github.com/rust-lang/rust/pull/154492#issuecomment-4237077272) but I'm certain it won't find anything either.
This is a theoretical breaking change that doesn't need any T-lang input IMHO since it's such a minute, niche and crystal clear bug that's not worth bothering them with (such a decision is not unprecedented). I'm adding it to the compatibility section of the release notes as is customary.
The Reference doesn't need updating since it didn't adopt this bug and thus accurately describes this part of the grammar as it used to be before 2021-02-23 and as it's meant to be.
The majority of the diff is doc comment additions & necessary UI test restructurings.
Eliminate `CrateMetadataRef`.
There are a number of things I dislike about `CrateMetadataRef`.
- It contains two fields `cstore` and `cdata`. The latter points to data within the former. It's like having an `Elem` type that has a reference to a vec element and also a reference to the vec itself. Weird.
- The `cdata` field gets a lot of use, and the `Deref` impl just derefs that field. The `cstore` field is rarely used.
- `CrateMetadataRef` is not a good name.
- Variables named `cdata` sometimes refer to values of this type and sometimes to values of type `CrateMetadata`, which is confusing.
The good news is that `CrateMetadataRef` is not necessary and can be replaced with `&CrateMetadata`. Why? Everywhere that `CrateMetadataRef` is used, a `TyCtxt` is also present, and the `CStore` is accessible from the `TyCtxt` with `CStore::from_tcx`.
So this commit removes `CrateMetadataRef` and replaces all its uses with `&CrateMetadata`. Notes:
- This requires adding only two uses of `CStore::from_tcx`, which shows how rarely the `cstore` field was used.
- `get_crate_data` now matches `get_crate_data_mut` more closely.
- A few variables are renamed for consistency, e.g. `data`/`cmeta` -> `cdata`.
- An unnecessary local variable (`local_cdata`) in `decode_expn_id` is removed.
- All the `CrateMetadataRef` methods become `CrateMetadata` methods, and their receiver changes from `self` to `&self`.
- `RawDefId::decode_from_cdata` is inlined and removed, because it has a single call site.
r? @mejrs
Move and clean up some ui test
`ui/reserved` -> `ui/keyword`
`ui/deref-patterns` -> `ui/pattern/deref-patterns`
`ui/unknown-unstable-lints` -> `ui/lint/unknown-lints`
Tests related to unknown_lints that were located above lint have also been moved to a subdirectory, and duplicate tests have been deleted.
And delete unnecessary `//@ check-fail`
r? Kivooeo
Generalize IO Traits for `Arc<T>` where `&T: IoTrait`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Related: rust-lang/rust#94744
## Description
After experimenting with rust-lang/rust#155625, I noticed `Seek` and `SeekFrom` can almost be moved to `core::io`. Unfortunately, the implementation of `Seek` for `Arc<File>` is a blocker for such a move, since `Arc` is not a fundamental type. This PR attempts to resolve this potential blocker by replacing the implementation with a more general alternative. An internal trait `IoHandle` has been added which types can implement to opt-in to `Read`/`Write`/`Seek` implementations for `Arc<Self>` as long as `&Self` implements said trait. Note that `BufRead` is excluded as the signature for `fill_buf` would require returning from a temporary.
Since this "blanket" implementation only applies to a single type which already implements the same traits, I believe this should have no user-facing impact.
If this PR was merged, rust-lang/rust#134190 could be replaced with a 2 line PR:
```rust
impl IoHandle for TcpStream {}
impl IoHandle for UnixStream {}
```
Likewise for any other types, a table of which can be found [here](https://github.com/rust-lang/libs-team/issues/504#issuecomment-2539569736). This is out of scope for this PR to avoid the need for an ACP.
---
## Notes
* See [this comment](https://github.com/rust-lang/rust/issues/154046#issuecomment-4303975612) for further details.
* No AI tooling of any kind was used during the creation of this PR.
Added a marker trait `IoHandle` which can be used by the standard library to opt-in types to a blanket implementation of the various IO traits on `Arc<T>` where `&T: IoTrait` for some `IoTrait`.
The marker is required to avoid types like `Arc<[u8]>` being included, since they don't have interior mutability and would not give expected results.
Fix classify_union to return Union for regular unions
Commit 623c7d7c4b accidentally changed the return value from REGULAR_UNION to RegularEnum when converting string literals to enum values. Commit b17670d3de then renamed RegularUnion to Union, but the buggy return statement remained unchanged. This caused unions to be misclassified as enums, preventing LLDB from displaying union field contents.
Fix array template arg lookup behavior
Minor logic error. `get_template_args` expects a matching `<`/`>` pair. We were passing in an array type with the beginning `<` removed, so the template arg behavior would fail.
Add docs about SDKs and C compilation on armv7a-vex-v5
This PR expands the documentation for armv7a-vex-v5 to fix broken links, add more information about SDKs, and create a new section about C compilation.
I'm not super familiar with how Rust chooses what linker configuration to use / how the `cc` crate chooses what compiler to use - is this configuration to make C compilation work usually something that would be included in the compiler itself? Either way, it requires a lot of extra work which is kind of unfortunate (downloading a separate compiler, adding it to path, setting up a bunch of environment variables, and making a cargo config for linking).
c-variadic: fix for sparc64
tracking issue: https://github.com/rust-lang/rust/issues/44930
Turns out it's a big-endian target that right-adjusts values in the stack slots.
Apparently these tests do get run occasionally, though i don't think test failures are usually turned into issues on this repo. I guess we could add an assembly test here too, though really you just have to run these tests. I've tried this locally with qemu, and it passes all c-variadic tests.
cc @thejpster @glaubitz
r? tgross35
Emscripten and OpenBSD exit out of the build script early. Since
02014b06c1a3 ("c-b: Turn `mem-unaligned` from a feature to a cfg"), this
meant that the exit happened before all `rustc-check-cfg`s had been
emitted.
Rework the logic so these only skip the C build rather than the rest of
configuration.
There are a number of things I dislike about `CrateMetadataRef`.
- It contains two fields `cstore` and `cdata`. The latter points to data
within the former. It's like having an `Elem` type that has a
reference to a vec element and also a reference to the vec itself.
Weird.
- The `cdata` field gets a lot of use, and the `Deref` impl just derefs
that field. The `cstore` field is rarely used.
- `CrateMetadataRef` is not a good name.
- Variables named `cdata` sometimes refer to values of this type and
sometimes to values of type `CrateMetadata`, which is confusing.
The good news is that `CrateMetadataRef` is not necessary and can be
replaced with `&CrateMetadata`. Why? Everywhere that `CrateMetadataRef`
is used, a `TyCtxt` is also present, and the `CStore` is accessible from
the `TyCtxt` with `CStore::from_tcx`.
So this commit removes `CrateMetadataRef` and replaces all its uses with
`&CrateMetadata`. Notes:
- This requires adding only two uses of `CStore::from_tcx`, which shows
how rarely the `cstore` field was used.
- `get_crate_data` now matches `get_crate_data_mut` more closely.
- A few variables are renamed for consistency, e.g. `data`/`cmeta` ->
`cdata`.
- An unnecessary local variable (`local_cdata`) in `decode_expn_id` is
removed.
- All the `CrateMetadataRef` methods become `CrateMetadata` methods, and
their receiver changes from `self` to `&self`.
- `RawDefId::decode_from_cdata` is inlined and removed, because it has a
single call site.
Simplify `Config::track_state`.
This is a callback used to track otherwise untracked state. It was added in rust-lang/rust#116731 for Clippy. (It was originally named `hash_untracked_state`, and examples in the rustc-dev-guide still use that name.) The `StableHasher` argument is unused, and probably has never been used. There is a FIXME comment pointing this out, which was added more than a year ago.
This commit removes the `StableHasher` callback argument. This also removes the need for `Options::untracked_state_hash`.
r? @bjorn3
Over time the landscape for myself has changed, and I no longer would
like to be officially listed as a maintainer of this target in Rust, so
I'm going to step down. There are still a number of others listed on
this target, however, so I'm sure they can address issues should they
come up.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#155469 (Account for titlecase in casing lints)
- rust-lang/rust#155644 (delegation: support self ty propagation for functions in free to trait reuse)
- rust-lang/rust#154957 (Fix ICE when const closure appears inside a non-const trait method)
- rust-lang/rust#155442 (Change keyword order for `impl` restrictions)
- rust-lang/rust#155561 (Use singular wording for single _ placeholders in type suggestions)
- rust-lang/rust#155637 (Fix E0191 suggestion for empty dyn trait args)
- rust-lang/rust#155661 (Remove `AttributeLintKind` variants - part 6)
Change keyword order for `impl` restrictions
Based on rust-lang/rust#155222, this PR reorders keywords in trait definitions to group restrictions with visibility. It changes the order from `pub(...) const unsafe auto impl(...) trait Foo {...}` to `pub(...) impl(...) const unsafe auto trait Foo {...}`.
Tracking issue for restrictions: rust-lang/rust#105077
r? @Urgau
cc @jhpratt
Fix ICE when const closure appears inside a non-const trait method
Fixesrust-lang/rust#153891
`hir_body_const_context()` unconditionally delegated to the parent's const context for const closures, returning `None` when the parent had no const context. This caused `mir_const_qualif()` to hit a `span_bug!`, since `mir_promoted()` had already decided to call it based on the closure's own syntactic constness. Fall back to `ConstContext::ConstFn` when the parent's const context is `None`, so that the const closure body is still properly const-checked rather than triggering an ICE.
Examining [another attempt](https://github.com/rust-lang/rust/pull/153900/changes) at this issue (which has already been closed), I thought that its approach represents a workaround fix to avoid inconsistencies in the caller of `mir_promoted()`, whereas I think the correct behavior is for `hir_body_const_context()` itself to return the proper value.
delegation: support self ty propagation for functions in free to trait reuse
This PR adds support for self types specified in free to trait reuse. Up to this point we always generated `Self` despite the fact whether self type was specified or not. Now we use it in signature inheritance. Moreover we no more generate `Self` for static methods. Part of rust-lang/rust#118212.
```rust
trait Trait<T> {
fn foo<const B: bool>(&self) {}
fn bar() {}
}
impl<T> Trait<T> for usize {}
reuse <usize as Trait>::foo;
// Desugaring (no `Self` as usize is specified)
fn foo<T, const B: bool>(self: &usize) {
<usize as Trait::<T>>::foo::<B>(self)
}
reuse Trait::bar;
// Desugaring (no `Self` as static method)
fn bar<T>() {
Trait::<T>::bar(); //~ERROR: type annotations needed
}
```
r? @petrochenkov
Jonathan Brouwer