Impl Ord for proc_macro::LineColumn
```rust
impl Ord for LineColumn {...}
impl PartialOrd for LineColumn {...}
```
for https://doc.rust-lang.org/nightly/proc_macro/struct.LineColumn.html.
The ordering is the natural one you would get by writing one line after another, where we compare line first, then compare columns within the same line.
Replace obligation construction with deref_steps()
1. Use `probe()` to avoid unwanted binding committing during `deref_steps()`.
2. Fixes#59819 again by using `deref_steps()`, make the code cleaner. And if we want to suggest multiple dereferences (like: `consider dereferencing the borrow: "****a"`) in the future, this change will make it easier to achieve.
Rollup of 7 pull requests
Successful merges:
- #71289 (Allow using `Self::` in doc)
- #72375 (Improve E0599 explanation)
- #72385 (Add some teams to prioritization exclude_labels)
- #72395 (Allow rust-highfive to label issues it creates.)
- #72453 (Add flag to open docs: x.py doc --open)
- #72459 (Add core::future::IntoFuture)
- #72461 (Clean up E0600 explanation)
Failed merges:
r? @ghost
Use `once_cell` crate instead of custom data structure
Internally, we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate, which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one.
This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver`, is owned by a well-known community member (cc @matklad), and has a stable release. cc @rust-lang/compiler
`once_cell` has a slightly more minimal API than `Once`, which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`.
r? @Mark-Simulacrum
Otherwise inserting it to the `Binder` used by `trait_ref` would cause
problems. This is just to be extra carefult: we aren't going to
start recommending that the user start using HKTs anytime soon.
`mk_obligation_for_def_id` is only correct if the trait and self type do
not have any substitutions. Use a different method,
`mk_trait_obligation_with_new_self_ty` that is more clear about what is
happening.
Add core::future::IntoFuture
This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps!
cc/ @rust-lang/wg-async-foundations
## References
- Original PR adding `IntoFuture` https://github.com/rust-lang/rust/pull/65244
- Open issue to re-land `IntoFuture` (assigned to me) https://github.com/rust-lang/rust/issues/67982
- Tracking issue for `IntoFuture` https://github.com/rust-lang/rust/issues/67644
Allow rust-highfive to label issues it creates.
This is my first meaningful PR, I am unsure how to test this code so any pointers would be welcome!
I am about 50% sure it works.
