Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
If late lifetime resolution fails for whatever reason, forward to RBV
the guarantee that an error was emitted - thereby eliminating the need
for a "hack" to suppress subsequent/superfluous error diagnostics.
Support syntax for one-line trait reuse
This PR adds support for reusing the whole trait with a one-line reuse syntax and is part of the delegation feature rust-lang/rust#118212:
```rust
trait T {
fn foo(&self);
}
struct S;
impl T for S { ... }
struct Wrapper(S);
reuse impl T for Wrapper { self.0 }
```
The core idea is that we already have support for glob reuse, so in this scenario we want to transform one-line reuse into a trait impl block with a glob reuse in the following way:
```rust
//Before
reuse impl T for Wrapper { self.0 }
//After
impl T for Wrapper {
reuse T::* { self.0 }
}
```
It seems like this task can be solved during parsing stage, when we encountered a one-line trait reuse, we can expand into this impl block right away, and the code which was already written to expand glob delegations will take care about the rest. We will copy trait path into glob reuse path.
The implementation of the transformation reuses already existing methods for `impl` parsing, however, we do not parse inner `impl` items, instead we parse "inner items" as delegation body. Thus, we do not have to deal with generics, consts, unsafe and other `impl` related features.
Other syntax possibility is trying to shorten one-line reuse by replacing `impl` keyword with `reuse` keyword:
```rust
reuse T for Wrapper { self.0 }
```
In this case implementation may become more complicated, and the syntax more confusing, as keywords such as `const` or `unsafe` will precede `reuse`, and there are also generics:
```rust
unsafe reuse<T1, T2> T for Wrapper { self.0 }
```
In the first (currently implemented) version reuse is placed in the beginning of the item, and it is clear that we will reuse trait implementation, while in the second, shorter version, the `reuse` keyword may be lost in generics and keywords that may precede `impl`.
r? ``@petrochenkov``
Support recursive delegation
This PR adds support for recursive delegations and is a part of the delegation feature rust-lang/rust#118212.
r? ``@petrochenkov``
Generate delegation error body when delegation is not resolved
This PR relates to the delegation feature rust-lang/rust#118212, it fixesrust-lang/rust#144594 ICE.
r? `@petrochenkov`
Fix ICE caused by invalid spans for shrink_file
Fixesrust-lang/rust#148732
There are two issues in this function:
1. the original issue is caused by a typo error, which is fixed in the first commit
2. another different ice(Patch span `7..7` is beyond the end of buffer `0`) will be reported after fixing the first one, is caused by spans cross file boundaries due to macro expansion. It is fixed in the second commit.
r? `@nnethercote`
edited: also fixesrust-lang/rust#148684, added a new testcase for it in the last commit.
Point at inner item when it uses generic type param from outer item or `Self`
Partially address rust-lang/rust#37892.
In E0401 generated in resolve:
```
error[E0401]: can't use generic parameters from outer item
--> $DIR/E0401.rs:4:39
|
LL | fn foo<T>(x: T) {
| - type parameter from outer item
LL | fn bfnr<U, V: Baz<U>, W: Fn()>(y: T) {
| ---- ^ use of generic parameter from outer item
| |
| generic parameter used in this inner function
|
help: try introducing a local generic parameter here
|
LL | fn bfnr<T, U, V: Baz<U>, W: Fn()>(y: T) {
| ++
```
In E0401 generated in hir_typeck:
```
error[E0401]: can't reference `Self` constructor from outer item
--> $DIR/do-not-ice-on-note_and_explain.rs:6:13
|
LL | impl<B> A<B> {
| ------------ the inner item doesn't inherit generics from this impl, so `Self` is invalid to reference
LL | fn d() {
LL | fn d() {
| - `Self` used in this inner item
LL | Self(1)
| ^^^^ help: replace `Self` with the actual type: `A`
```
```
error[E0277]: the trait bound `[[u16; 3]; 2]: Bar` is not satisfied
--> $DIR/issue-67185-2.rs:21:6
|
LL | impl Foo for FooImpl {}
| ^^^ the trait `Bar` is not implemented for `[[u16; 3]; 2]`
|
help: the following other types implement trait `Bar`
--> $DIR/issue-67185-2.rs:9:1
|
LL | impl Bar for [u16; 4] {}
| ^^^^^^^^^^^^^^^^^^^^^ `[u16; 4]`
LL | impl Bar for [[u16; 3]; 3] {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `[[u16; 3]; 3]`
note: required by a bound in `Foo`
--> $DIR/issue-67185-2.rs:14:30
|
LL | trait Foo
| --- required by a bound in this trait
LL | where
LL | [<u8 as Baz>::Quaks; 2]: Bar,
| ^^^ required by this bound in `Foo`
```
Do not assert that a change in global cache only happens when concurrent
Fixesrust-lang/trait-system-refactor-initiative#234
I think it should just be safe to remove this assert (rather than delaying a bug). If the previous and current result are the same, I wouldn't expect issues.
r? lcnr
When encountering an unmet trait bound, point at local type that doesn't implement the trait:
```
error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied
--> $DIR/issue-64855.rs:9:19
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Foo` is not implemented for `Bar<T>`
--> $DIR/issue-64855.rs:9:1
|
LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ;
| ^^^^^^^^^^^^^^^^^
```
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
When we don't actually print out a shortened type we don't need the "use `--verbose`" note.
On E0599 show type identity to avoid expanding the receiver's generic parameters.
Unify wording on `long_ty_path` everywhere.
Improve diagnostics for usage of qualified paths within tuple struct exprs/pats
For patterns the old diagnostic was just incorrect, but I also added machine applicable suggestions.
For context, this special cases errors for `<T as Trait>::Assoc(..)` patterns and expressions (latter is just a call). Tuple struct patterns and expressions both live in the value namespace, so they are not forwarded through associated *types*.
r? ``@jdonszelmann``
cc ``@petrochenkov`` in https://github.com/rust-lang/rust/pull/80080#issuecomment-800630582 you were wondering why it doesn't work for types, that's why — tuple patterns are resolved in the value namespace.
Stabilize `cfg_boolean_literals`
Closes#131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating
--
# Stabilization Report
## General design
### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
[RFC 3695](https://github.com/rust-lang/rfcs/pull/3695), none.
### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
None
### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
None
## Has a call-for-testing period been conducted? If so, what feedback was received?
Yes; only positive feedback was received.
## Implementation quality
### Summarize the major parts of the implementation and provide links into the code (or to PRs)
Implemented in [#131034](https://github.com/rust-lang/rust/pull/131034).
### Summarize existing test coverage of this feature
- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](6d71251cf9/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](6d71251cf9/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`
### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
The above mentioned issue; it should not block as it interacts with another unstable feature.
### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None
### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)
### Which tools need to be adjusted to support this feature. Has this work been done?
`rustdoc`'s unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.
## Type system and execution rules
### What updates are needed to the reference/specification? (link to PRs when they exist)
A few lines to be added to the reference for configuration predicates, specified in the RFC.
