…d anywhere and sugetion of type with method when found.

 (and thus exposed underlying issue rust-lang#85561).

(removing confusing comment from my test, since the comment reflects the bad undesirable behavior that is being fixed here.)

Co-authored-by: Esteban Kuber <[email protected]>

test THIR unsafeck too

Co-authored-by: Léo Lanteri Thauvin <[email protected]>

Recent commits to cc have helped to address rust-lang#83043 and rust-lang#43468

This removes a workaround for rust-lang#24159, which has been fixed.

…estebank

E0599 suggestions and elision of generic argument if no canditate is found

fixes rust-lang#81576
changes: In error E0599 (method not found) generic argument are eluded if the method was not found anywhere. If the method was found in another inherent implementation suggest that it was found elsewhere.

Example
```rust

struct Wrapper<T>(T);

struct Wrapper2<T> {
    x: T,
}

impl Wrapper2<i8> {
    fn method(&self) {}
}

fn main() {
    let wrapper = Wrapper(i32);
    wrapper.method();
    let wrapper2 = Wrapper2{x: i32};
    wrapper2.method();
}
```

```
Error[E0599]: no method named `method` found for struct `Wrapper<_>` in the current scope
....
error[E0599]: no method named `method` found for struct `Wrapper2<i32>` in the current scope
...
   = note: The method was found for Wrapper2<i8>.

```
I am not very happy with the ```no method named `test` found for struct `Vec<_, _>` in the current scope```. I think it might be better to show only one generic argument `Vec<_>` if there is a default one. But I haven't yet found a way to do that,

…raints-61997, r=jackh726

stabilize member constraints

Stabilizes the use of "member constraints" in solving `impl Trait` bindings. This is a step towards stabilizing a "MVP" of "named impl Trait".

# Member constraint stabilization report

| Info | |
| --- | --- |
| Tracking issue | [rust-lang#61997](rust-lang#61997) |
| Implementation history | [rust-lang#61775] |
| rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) |
| Complications | [rust-lang#61773] |

[rust-lang#61775]: rust-lang#61775
[rust-lang#61773]: rust-lang#61773

## Background

Member constraints are an extension to our region solver that was introduced to make async fn region solving tractable. There are used in situations like the following:

```rust
fn foo<'a, 'b>(...) -> impl Trait<'a, 'b> { .. }
```

The problem here is that every region R in the hidden type must be equal to *either* `'a` *or* `'b` (or `'static`). This cannot be expressed simply via 'outlives constriants' like `R: 'a`. Therefore, we introduce a 'member constraint' `R member of ['a, 'b]`.

These constraints were introduced in [rust-lang#61775]. At the time, we kept them feature gated and used them only for `impl Trait` return types that are derived from `async fn`. The intention, however, was always to support them in other contexts once we had time to gain more experience with them.

**In the time since their introduction, we have encountered no surprises or bugs due to these member constraints.** They are tested extensively as part of every async function that involves multiple unrelated lifetimes in its arguments.

## Tests

The behavior of member constraints is covered by the following tests:

* [`src/test/ui/async-await/multiple-lifetimes`](https://github.com/rust-lang/rust/tree/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/async-await/multiple-lifetimes) -- tests using the async await, which are mostly already stabilized
* [`src/test/ui/impl-trait/multiple-lifetimes.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/impl-trait/multiple-lifetimes.rs)
* [`src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs)
* [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs)
* [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs)

These tests cover a number of scenarios:

* `-> implTrait<'a, 'b>` with unrelated lifetimes `'a` and `'b`, as described above
* `async fn` that returns an `impl Trait` like the previous case, which desugars to a kind of "nested" impl trait like `impl Future<Output = impl Trait<'a, 'b>>`

## Potential concerns

There is a potential interaction with `impl Trait` on local variables, described in [rust-lang#61773]. The challenge is that if you have a program like:

```rust=
trait Foo<'_> { }
impl Foo<'_> for &u32 { }

fn bar() {
  let x: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1`
}
```

then we would wind up with `'0 member of ['1, 'static]`, where `'0` is the region variable in the hidden type (`&'0 u32`) and `'1` is the region variable in the bounds `Foo<'1>`. This is tricky because both `'0` and `'1` are being inferred -- so making them equal may have other repercussions.

That said, `impl Trait` in bindings are not stable, and the implementation is pretty far from stabilization. Moreover, the difficulty highlighted here is not due to the presence of member constraints -- it's inherent to the design of the language. In other words, stabilizing member constraints does not actually cause us to accept anything that would make this problem any harder.

So I don't see this as a blocker to stabilization of member constraints; it is potentially a blocker to stablization of `impl trait` in let bindings.

…disjoint-fields-gate, r=nikomatsakis

 readd capture disjoint fields gate

This readds a feature gate guard that was added in PR rust-lang#83521. (Basically, there were unintended consequences to the code exposed by removing the feature gate guard.)

The root bug still remains to be resolved, as discussed in issue rust-lang#85561. This is just a band-aid suitable for a beta backport.

Cc issue rust-lang#85435

Note that the latter issue is unfixed until we backport this (or another fix) to 1.53 beta

…nkov

Get rid of PreviousDepGraph.

Its only role is to access the `SerializedDepGraph`.

Update cc

Recent commits have improved `cc`'s finding of MSVC tools on Windows. In particular it should help to address these issues: rust-lang#83043 and rust-lang#43468

Remove Iterator #[rustc_on_unimplemented]s that no longer apply.

Now that `IntoIterator` is implemented for arrays, all the `rustc_on_unimplemented` for arrays of ranges (e.g. `for _ in [1..3] {}`) no longer apply, since they are now valid Rust.

Separated these from rust-lang#85670, because we should discuss a potential new (clippy?) lint for these.

Until Rust 1.52, `for _ in [1..3] {}` produced:

```
error[E0277]: `[std::ops::Range<{integer}>; 1]` is not an iterator
 --> src/main.rs:2:14
  |
2 |     for _ in [1..3] {}
  |              ^^^^^^ if you meant to iterate between two values, remove the square brackets
  |
  = help: the trait `std::iter::Iterator` is not implemented for `[std::ops::Range<{integer}>; 1]`
  = note: `[start..end]` is an array of one `Range`; you might have meant to have a `Range` without the brackets: `start..end`
  = note: required by `std::iter::IntoIterator::into_iter`
```

But in Rust 1.53 and later, it compiles fine. It iterates over the array by value, for one iteration with the element `1..3`.

This is probably a mistake, which is no longer caught. Should we have a lint for it? Should Clippy have a lint for it?

cc ``@estebank`` ``@flip1995``

cc rust-lang#84513

…r=m-ou-se

Add inline attr to CString::into_inner so it can optimize out NonNull checks

It seems that currently if you convert any of the standard library's container to a pointer and then to a NonNull pointer, all will optimize out the NULL check except `CString`(https://godbolt.org/z/YPKW9G5xn),
because for some reason `CString::into_inner` isn't inlined even though it's a private function that should compile into a simple `mov` instruction.

Adding a simple `#[inline]` attribute solves this, code example:
```rust
use std::ffi::CString;
use std::ptr::NonNull;

pub fn cstring_nonull(mut n: CString) -> NonNull<i8> {
    NonNull::new(CString::into_raw(n)).unwrap()
}
```

assembly before:
```asm
__ZN3wat14cstring_nonull17h371c755bcad76294E:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	callq	__ZN3std3ffi5c_str7CString10into_inner17h28ece07b276e2878E
	testq	%rax, %rax
	je	LBB0_2
	popq	%rbp
	retq
LBB0_2:
	leaq	l___unnamed_1(%rip), %rdi
	leaq	l___unnamed_2(%rip), %rdx
	movl	$43, %esi
	callq	__ZN4core9panicking5panic17h92a83fa9085a8f73E
	.cfi_endproc

	.section	__TEXT,__const
l___unnamed_1:
	.ascii	"called `Option::unwrap()` on a `None` value"

l___unnamed_3:
	.ascii	"wat.rs"

	.section	__DATA,__const
	.p2align	3
l___unnamed_2:
	.quad	l___unnamed_3
	.asciz	"\006\000\000\000\000\000\000\000\006\000\000\000(\000\000"
```

Assembly after:
```asm
__ZN3wat14cstring_nonull17h9645eb9341fb25d7E:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	movq	%rdi, %rax
	popq	%rbp
	retq
	.cfi_endproc
```

(Related discussion on zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/NonNull.20From.3CBox.3CT.3E.3E)

…fJung

Remove unneeded workaround

This removes a workaround for rust-lang#24159, which has been fixed.