Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stabilize member constraints #84701

Merged

Conversation

nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Apr 29, 2021

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/rust#61997
Implementation history rust-lang/rust#61775
rustc-dev-guide coverage link
Complications rust-lang/rust#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:

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/rust#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:

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/rust#61773. The challenge is that if you have a program like:

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.

@rust-highfive
Copy link
Collaborator

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 29, 2021
@nikomatsakis nikomatsakis added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Apr 29, 2021
@nikomatsakis
Copy link
Contributor Author

I've marked this for @rust-lang/lang, but I'd like to cc @rust-lang/compiler, @rust-lang/wg-traits, and especially @matthewjasper for comment.

@nikomatsakis nikomatsakis added F-member_constraints `#[feature(member_constraints)]` I-nominated labels Apr 29, 2021
Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small typo.

But overall, this seems extremely straightforward to me. From a language design standpoint, I don't see why the lifetimes in an impl Trait should have to relate to each other (we don't have that requirement for structs, for example). From a implementation standpoint, the fact that this has been effectively stable in async fns provides good evidence the correct implementation is as correct as it can be and that this is worth stabilizing more generally.

@nikomatsakis nikomatsakis force-pushed the stabilize-member-constraints-61997 branch from d6a7603 to 4dc3316 Compare April 29, 2021 16:26
@nikomatsakis
Copy link
Contributor Author

@rfcbot fcp merge

As discussed in the lang-team meeting.

@rfcbot
Copy link

rfcbot commented May 6, 2021

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels May 6, 2021
@rfcbot
Copy link

rfcbot commented May 11, 2021

🔔 This is now entering its final comment period, as per the review above. 🔔

Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stabilization PR here is pretty simple (as it should be). One comment, but r=me on this when FCP finishes

compiler/rustc_feature/src/accepted.rs Outdated Show resolved Hide resolved
@bors
Copy link
Contributor

bors commented May 19, 2021

☔ The latest upstream changes (presumably #85458) made this pull request unmergeable. Please resolve the merge conflicts.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels May 21, 2021
@rfcbot
Copy link

rfcbot commented May 21, 2021

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label May 21, 2021
@nikomatsakis nikomatsakis force-pushed the stabilize-member-constraints-61997 branch from 2747857 to a937f25 Compare May 24, 2021 17:32
@nikomatsakis
Copy link
Contributor Author

@bors r=jackh726

@bors
Copy link
Contributor

bors commented May 24, 2021

📌 Commit a937f25 has been approved by jackh726

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 24, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this pull request May 25, 2021
…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.
@bors
Copy link
Contributor

bors commented May 25, 2021

⌛ Testing commit a937f25 with merge 6ea940b75105c23bcd7049a64b6a2cfe8e9cf8aa...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented May 25, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 25, 2021
@lqd
Copy link
Member

lqd commented May 25, 2021

(the compare-mode=nll tests need blessing)

@nikomatsakis nikomatsakis force-pushed the stabilize-member-constraints-61997 branch from a937f25 to be4ae9d Compare May 26, 2021 10:01
@nikomatsakis nikomatsakis force-pushed the stabilize-member-constraints-61997 branch from be4ae9d to 128d385 Compare May 26, 2021 10:01
@nikomatsakis
Copy link
Contributor Author

@bors r=jackh726

@bors
Copy link
Contributor

bors commented May 26, 2021

📌 Commit b3054d2 has been approved by jackh726

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 26, 2021
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 26, 2021
…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.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 27, 2021
…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.
This was referenced May 27, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request May 27, 2021
Rollup of 8 pull requests

Successful merges:

 - rust-lang#84221 (E0599 suggestions and elision of generic argument if no canditate is found)
 - rust-lang#84701 (stabilize member constraints)
 - rust-lang#85564 ( readd capture disjoint fields gate)
 - rust-lang#85583 (Get rid of PreviousDepGraph.)
 - rust-lang#85649 (Update cc)
 - rust-lang#85689 (Remove Iterator #[rustc_on_unimplemented]s that no longer apply.)
 - rust-lang#85719 (Add inline attr to CString::into_inner so it can optimize out NonNull checks)
 - rust-lang#85725 (Remove unneeded workaround)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 3530a78 into rust-lang:master May 27, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 27, 2021
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label May 27, 2021
@jonas-schievink jonas-schievink added the relnotes Marks issues that should be documented in the release notes of the next release. label Jul 17, 2021
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Aug 12, 2021
Pkgsrc changes:
 * Bump bootstrap requirements to 1.53.0.
 * Adjust patches, adapt to upstream changes, adjust cargo checksums
 * If using an external llvm, require >= 10.0

Upsteream changes:

Version 1.54.0 (2021-07-29)
============================

Language
-----------------------

- [You can now use macros for values in built-in attribute macros.][83366]
  While a seemingly minor addition on its own, this enables a lot of
  powerful functionality when combined correctly. Most notably you can
  now include external documentation in your crate by writing the following.
  ```rust
  #![doc = include_str!("README.md")]
  ```
  You can also use this to include auto-generated modules:
  ```rust
  #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
  mod generated;
  ```

- [You can now cast between unsized slice types (and types which contain
  unsized slices) in `const fn`.][85078]
- [You can now use multiple generic lifetimes with `impl Trait` where the
   lifetimes don't explicitly outlive another.][84701] In code this means
   that you can now have `impl Trait<'a, 'b>` where as before you could
   only have `impl Trait<'a, 'b> where 'b: 'a`.

Compiler
-----------------------

- [Rustc will now search for custom JSON targets in
  `/lib/rustlib/<target-triple>/target.json` where `/` is the "sysroot"
  directory.][83800] You can find your sysroot directory by running
  `rustc --print sysroot`.
- [Added `wasm` as a `target_family` for WebAssembly platforms.][84072]
- [You can now use `#[target_feature]` on safe functions when targeting
  WebAssembly platforms.][84988]
- [Improved debugger output for enums on Windows MSVC platforms.][85292]
- [Added tier 3\* support for `bpfel-unknown-none`
   and `bpfeb-unknown-none`.][79608]

\* Refer to Rust's [platform support page][platform-support-doc] for more
   information on Rust's tiered platform support.

Libraries
-----------------------

- [`panic::panic_any` will now `#[track_caller]`.][85745]
- [Added `OutOfMemory` as a variant of `io::ErrorKind`.][84744]
- [ `proc_macro::Literal` now implements `FromStr`.][84717]
- [The implementations of vendor intrinsics in core::arch have been
   significantly refactored.][83278] The main user-visible changes are
   a 50% reduction in the size of libcore.rlib and stricter validation
   of constant operands passed to intrinsics. The latter is technically
   a breaking change, but allows Rust to more closely match the C vendor
   intrinsics API.

Stabilized APIs
---------------

- [`BTreeMap::into_keys`]
- [`BTreeMap::into_values`]
- [`HashMap::into_keys`]
- [`HashMap::into_values`]
- [`arch::wasm32`]
- [`VecDeque::binary_search`]
- [`VecDeque::binary_search_by`]
- [`VecDeque::binary_search_by_key`]
- [`VecDeque::partition_point`]

Cargo
-----

- [Added the `--prune <spec>` option to `cargo-tree` to remove a package from
  the dependency graph.][cargo/9520]
- [Added the `--depth` option to `cargo-tree` to print only to a certain depth
  in the tree ][cargo/9499]
- [Added the `no-proc-macro` value to `cargo-tree --edges` to hide procedural
  macro dependencies.][cargo/9488]
- [A new environment variable named `CARGO_TARGET_TMPDIR` is
  available.][cargo/9375]
  This variable points to a directory that integration tests and
  benches can use as a "scratchpad" for testing filesystem operations.

Compatibility Notes
-------------------
- [Mixing Option and Result via `?` is no longer permitted in
  closures for inferred types.][86831]
- [Previously unsound code is no longer permitted where different
  constructors in branches could require different lifetimes.][85574]
- As previously mentioned the [`std::arch` instrinsics now uses
  stricter const checking][83278] than before and may reject some
  previously accepted code.
- [`i128` multiplication on Cortex M0+ platforms currently
  unconditionally causes overflow when compiled with `codegen-units
  = 1`.][86063]

[85574]: rust-lang/rust#85574
[86831]: rust-lang/rust#86831
[86063]: rust-lang/rust#86063
[86831]: rust-lang/rust#86831
[79608]: rust-lang/rust#79608
[84988]: rust-lang/rust#84988
[84701]: rust-lang/rust#84701
[84072]: rust-lang/rust#84072
[85745]: rust-lang/rust#85745
[84744]: rust-lang/rust#84744
[85078]: rust-lang/rust#85078
[84717]: rust-lang/rust#84717
[83800]: rust-lang/rust#83800
[83366]: rust-lang/rust#83366
[83278]: rust-lang/rust#83278
[85292]: rust-lang/rust#85292
[cargo/9520]: rust-lang/cargo#9520
[cargo/9499]: rust-lang/cargo#9499
[cargo/9488]: rust-lang/cargo#9488
[cargo/9375]: rust-lang/cargo#9375
[`BTreeMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_keys
[`BTreeMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.into_values
[`HashMap::into_keys`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_keys
[`HashMap::into_values`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.into_values
[`arch::wasm32`]: https://doc.rust-lang.org/core/arch/wasm32/index.html
[`VecDeque::binary_search`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search
[`VecDeque::binary_search_by`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by
[`VecDeque::binary_search_by_key`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.binary_search_by_key
[`VecDeque::partition_point`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.partition_point
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-member_constraints `#[feature(member_constraints)]` finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.